Quelle est la différence entre un arrêt à 18h00 et un arrêt à 18h00?
at 18:00 shutdown now et shutdown 18:00, commencent-ils le même service? Fonctionnent-ils de la même manière?
at 18:00 shutdown now crée un travail "at", qui est exécuté à l'heure spécifiée par le démon at ou peut-être le démon cron, selon votre système.
shutdown 18:00 dé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 ex. 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:00 créera un /run/nologin fichier 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.
Et maintenant, la réponse systemd.
Si vous avez CentOS 7, vous avez un système d'exploitation systemd et la réponse est différente.
at 18:00 shutdown now planifie toujours via le sous-système at, mais cette commande shutdown, ainsi que celle que vous invoquez directement avec shutdown 18:00, est différent. Il s'agit en fait du programme systemctl de systemd. systemctl fait les choses différemment.
Tout d'abord, systemctl envoie la demande d'arrêt planifié pour qu'elle soit traitée par un démon, un peu comme dans le cas at. C'est un démon systemd, cependant, spécifiquement logind (le systemd-shutdownd dæmon ayant été supprimé de systemd en mai 2015, ce changement ayant depuis été répercuté sur les versions mineures ultérieures de CentOS 7), et non le sous-système at. systemctl communique un protocole interne à un courtier Desktop Bus (à l'échelle du système) qui à son tour communique avec logind.
Ainsi, comme dans le cas at, il n'y a pas de processus shutdown assis là, comptant et générant les messages wall. 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. Tout comme avec at.
Il y a encore des messages , contrairement au cas at, mais ils sont émis par logind. Contrairement au cas at, le travail planifié ne persiste pas lors des redémarrages du système, donc un arrêt réel annule un planifié. Il y a un fichier dans le système de fichiers, mais il est sous /run/systemd/shutdown qui est un stockage non persistant.
D'autres différences sont qu'il ne peut y avoir qu'un un arrêt planifié à la fois, tandis que l'on peut soumettre plusieurs travaux at, et Policy Kit appliquer des règles à shutdown s'exécuter dans un contexte de non-session de connexion en tant que travail at qui sont différentes des règles appliquées à shutdown s'exécuter dans un contexte de session de connexion. Ce dernier peut être plus permissif, permettant (par exemple) à un utilisateur non privilégié qui est connecté à la session de connexion active d'arrêter le système.