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