Runit

[Jeff <sysinit@yandex.com>]

>>  If something kills runsvdir, then runit immediately enters
>>  stage 3, and reboots the system. This is an acceptable response
>>  to the scanner dying, but is not the same thing as supervising
>>  it. If runsvdir's death is accidental, the system goes through
>>  an unnecessary reboot.
>
> If the /etc/runit/2 process exits with code 111 or gets killed by a
> signal, the runit program is actually supposed to respawn it,
> according to its man page. I believe this counts as supervising at
> least one process, so it would put runit in the "correct init" camp :)
>
> There is code that checks the 'wstat' value returned by a
> wait_nohang(&wstat) call that reaps the /etc/runit/2 process, however,
> it is executed only if wait_exitcode(wstat) != 0. On my computer,
> wait_exitcode() returns 0 if its argument is the wstat of a process
> killed by a signal, so runit indeed spawns /etc/runit/3 instead of
> respawning /etc/runit/2 when, for example, I point a gun at runsvdir
> on purpose and use a kill -int command specifying its PID. Changing
> the condition to wait_crashed(wstat) || (wait_exitcode(wstat) != 0)
> makes things work as intended.

that is again one of several runit problems. among them:

- see above
- no setsid(2) for child procs by default in "runsv"
- having only runsv managing the log pipe.
- runit-init requires rw fs access without the slightest need
  (setting the +x bit of  the /etc/runit/(stopit,reboot) files
  which could indeed reside on a tmpfs in /run and be
  symlinks have symlinks pointing to them (that is done in
  Void Linux)
- problems with log files while bringing down the system.
  i never encountered that with daemontools-encore, perp(d)
  and s6.

so it is a quite dated project that clearly shows its age.
i would recommend against using it at all (except its
"chpst" and "utmpset" utilities).