at 18:00 shutdown now
and shutdown 18:00
, are they starting the same service? Do they work the same way?
2 Answers
at 18:00 shutdown now
creates an "at" job, which is performed at the specified time by the at
daemon or perhaps the cron
daemon, depending on your system.
shutdown 18:00
starts a process in your shell that waits until the specified time and then performs the shutdown. This command can be terminated if e.g. your shell session is terminated.
The net result in most cases will be the same: the system is shutdown at 18:00.
One difference is that if you use at
, the job will be stored and if the system is shutdown by some other means before 18:00, upon booting again the job will still be waiting to be run; if the time is already passed, the shutdown will be performed immediately which could be quite unexpected.
Another difference is that shutdown 18:00
will create a /run/nologin
file 5 minutes before the scheduled time to prevent people logging in after that moment. Also broadcast messages will be sent to warn logged in users that the system is about to be shutdown.
You need to take account these differences to decide which to use.
-
1"
shutdown 18:00
starts a process in your shell that waits". What if you log out before then?– RonJohnAug 28, 2018 at 18:46 -
1@RonJohn: Then it depends if you used
nohup
ordisown
or whatever, if logging out normally kills running background processes. Different systems can have different defaults for that. (I'm assuming that there really is asudo shutdown
process still running, rather it just signallinginit
to start a shutdown timer. The latter might actually be what happens, but I haven't checked recently. Oh, but @JdeBP has; see that answer) Aug 29, 2018 at 5:02 -
Is it really possible to set up
at
so it works viacron
instead ofatd
?– terdon ♦Aug 29, 2018 at 8:25 -
3There's a diamond moderator who has not read How to Ask. (-: You will find that this question was asked four years ago at unix.stackexchange.com/questions/147643 .– JdeBPAug 29, 2018 at 10:17
-
"Also broadcast messages will be sent to warn logged in users that the system is about to be shutdown." I'd say this is the most important difference in servers that have many users, I would highlight it more in this answer.– JiKAug 30, 2018 at 10:21
And now, the systemd answer.
If you have CentOS 7, you have a systemd operating system and the answer is different.
at 18:00 shutdown now
still schedules via the at
subsystem, but that shutdown
command, as well as the one that you invoke directly with shutdown 18:00
, is different. It's actually systemd's systemctl
program. systemctl
does things differently.
First of all, systemctl
sends the scheduled shutdown request off to be processed by a dæmon, pretty much like in the at
case. This is a systemd dæmon, though, specifically logind
(the systemd-shutdownd
dæmon having been removed from systemd in May 2015, which change has since percolated through to later minor versions of CentOS 7), not the at
subsystem. systemctl
speaks an internal protocol to a (system-wide) Desktop Bus broker which in turn communicates with logind
.
So, like in the at
case, there's no shutdown
process sitting there counting down and spawning the wall
messages. So one can log out and this will not affect the schedule, and cancelling is not as simple as merely interrupting/killing the foreground process of the login session. Just like with at
.
There are still messages, unlike in the at
case, but they are issued by logind
. Also unlike the at
case, the scheduled job does not persist across system restarts, so an actual shutdown cancels a scheduled one. There is a file in the filesystem, but it is under /run/systemd/shutdown
which is non-persistent storage.
Further differences are that there can be only one scheduled shutdown at a time, whereas one can submit multiple at
jobs, and Policy Kit will apply rules to shutdown
run in non-login-session context as an at
job that are different to the rules applied to shutdown
run in login-session context. The latter might be more permissive, allowing (say) an unprivileged user who is logged in to the active login session to shut down the system.