Réponses:
at 18:00 shutdown nowcrée un travail "at", qui est exécuté à l'heure spécifiée par le atdémon ou peut-être le crondémon, selon votre système.
shutdown 18:00démarre un processus dans votre shell qui attend l'heure spécifiée, puis effectue l'arrêt. Cette commande peut être interrompue si, par exemple, votre session shell est terminée.
Le résultat net dans la plupart des cas sera le même: le système est arrêté à 18h00.
Une différence est que si vous utilisez at, le travail sera stocké et si le système est arrêté par un autre moyen avant 18h00, au redémarrage, le travail attendra toujours d'être exécuté; si le temps est déjà écoulé, l'arrêt sera effectué immédiatement, ce qui pourrait être tout à fait inattendu.
Une autre différence est que shutdown 18:00cela créera un /run/nologinfichier 5 minutes avant l'heure prévue pour empêcher les gens de se connecter après ce moment. Des messages diffusés seront également envoyés pour avertir les utilisateurs connectés que le système est sur le point d'être arrêté.
Vous devez tenir compte de ces différences pour décider lequel utiliser.
nohupou disownautre chose, si la déconnexion tue normalement les processus d'arrière-plan en cours d'exécution . Différents systèmes peuvent avoir des valeurs par défaut différentes pour cela. (Je suppose qu'il y a vraiment un sudo shutdownprocessus en cours d'exécution, plutôt qu'il signale simplement le initdémarrage d'une minuterie d'arrêt. Ce dernier pourrait en fait être ce qui se passe, mais je n'ai pas vérifié récemment. Oh, mais @JdeBP l'a fait; voyez cette réponse )
atque cela fonctionne via cronau lieu de atd?
Si vous avez CentOS 7, vous avez un système d'exploitation systemd et la réponse est différente.
at 18:00 shutdown nowplanifie toujours via le atsous - système, mais cette shutdowncommande, ainsi que celle avec laquelle vous invoquez directement shutdown 18:00, est différente. C'est en fait le systemctlprogramme de systemd . systemctlfait les choses différemment.
Tout d'abord, systemctlenvoie la demande d'arrêt planifié pour qu'elle soit traitée par un démon, un peu comme dans le atcas. Il s'agit d'un dæmon systemd, cependant, spécifiquement logind(le systemd-shutdownddæmon ayant été supprimé de systemd en mai 2015, dont le changement s'est depuis infiltré dans les versions mineures ultérieures de CentOS 7), pas du atsous - système. systemctlcommunique un protocole interne à un courtier de bus de bureau (à l'échelle du système) qui à son tour communique avec logind.
Donc, comme dans le atcas, il n'y a pas de shutdownprocessus de décompte et de génération des wallmessages. Ainsi, on peut se déconnecter et cela n'affectera pas le calendrier, et l'annulation n'est pas aussi simple que simplement interrompre / tuer le processus de premier plan de la session de connexion. Comme avec at.
Il y a toujours des messages, contrairement au atcas, mais ils sont émis par logind. Contrairement au atcas, le travail planifié ne persiste pas lors des redémarrages du système, donc un arrêt réel annule un travail planifié. Il y a un fichier dans le système de fichiers, mais il est sous /run/systemd/shutdownlequel se trouve un stockage non persistant.
D'autres différences sont qu'il ne peut y avoir qu'un seul arrêt planifié à la fois, alors que l'on peut soumettre plusieurs attravaux, et Policy Kit appliquera les règles à shutdownexécuter dans un contexte de non-session de connexion en tant que attravail différent des règles appliquées pour shutdowns'exécuter dans contexte de session de connexion. Ce dernier peut être plus permissif, permettant (par exemple) à un utilisateur non privilégié connecté à la session de connexion active de fermer le système.
shutdown 18:00msgstr " démarre un processus dans votre shell qui attend". Et si vous vous déconnectez avant cela?