>but one can do without it and call the shutdown script by hand
>which in the end does the reboot(2) call itself, thats perfectly
>possible and the classical BSD way, so process #1 does not even
>need to do the system shutdown itself.
That's relying on a behaviour that Linux implements, and possibly
BSD too, but that is not specified in POSIX: that the process
that does a kill(-1, signal) is not affected by the kill() call.
Before the reboot(2) system call, at some point you need to
kill all processes ("kill -9 -1") so you can unmount filesystems
and *then* call reboot(2).
With the extended behaviour, the process that performs the kill -9 -1
survives, and can then go on to "stage 4", i.e. unmounting everything
and telling the hardware to halt/reboot. But that is not POSIX.
POSIX specifies that the kill signal will be sent to all processes
"excluding an unspecified set of system processes". pid 1 is naturally
part of those "system processes", but a shell, or a program that
performs the shutdown sequence, with a random pid, cannot be.
The only ways to perform a proper shutdown sequence that strictly
conforms to POSIX are:
- do it in pid 1
- do it *under a supervision tree*. When the shutdown sequence kills
everything, it may also kill itself; if it is the case, it is restarted
by the supervision tree, and can then go on to stage 4.
The shutdown sequence generated by the current s6-linux-init-maker
does the former. The shutdown sequence in the upcoming s6-linux-init
performs the latter.
It is not strictly necessary to do so on Linux, and apparently on
BSD either, since those systems ensure the survival of the process
sending the big nuke. But you need to be aware of this implementation
detail before advertising the "classical BSD way". :)
--
Laurent
Received on Fri May 03 2019 - 19:25:47 UTC