is it required to call kill() from process #1 ?

[Jeff <sysinit@yandex.com>]

> 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).

indeed.

> 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.

true when using kill( -1, sig ).

> 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.

there are at least to other solutions to the killall problem:

* on Linux you probably have the procfs mounted, on the BSDs, Solaris,
  and AIX you can use kvm to do the following:
  find all running processes (except your own and possibly your own
  session id) via the procfs or kvm and signal them, your own process
  (and session) are now not signaled (this is how the killall5 utility
  actually works). in the case of kvm you do not even need to have the
  procfs mounted.

* if you can not rely on such a mechanism you can still do a brute-force
  search to find running processes along this pseudo code lines:

  pid_t p ;
  const pid_t mypid = getpid () ;
  const ... int u = get_current_upper_limit_for_the_number_of_procs () ;

  for ( p = 2 ; u >= p ; ++ p ) {
    // this ignores session ids
    if ( mypid != p && 0 == kill ( p, 0 ) ) {
      (void) kill ( p, signal ) ;
    }
  }

i personally do it from process #1 aswell since calling kill( -1, sig )
from there is much simpler and should be faster (work is done by the kernel,
no need to find all running processes by ourselves).

> 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.

i prefer to call it "stage 3b". :PP
stage 3a terminates known services.
then everything is killed by process #1 and stage 3b is run thereafter
to complete the remaining shutdown tasks like swapoff and unmounting
the fs.

BTW: i do not un/remount pseudo fs like procfs, sysfs, devtmpfs etc
whose mountpoints are directly located on the root fs or via a direct
path of pseudo fs from the root fs. works well when one does not use
initram and the like. could this cause trouble somewhere ?

> 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.

ok, when will you release it ? you made me curious ...

> 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". :)

:PP

actually it may not since it looks like inherited behaviour from even older
Unix implentations' init. the Linux SysV init incarnation and minit also do
not run any of the system shutdown tasks themselves but instead delegate
these to subprocesses.