On Fri, 17 Jun 2016 12:02:35 +0200
Didier Kryn <kryn@???> wrote:

>      However I think init must do more on the long run than reaping 
> zombies. It should ensure in some way that at least someone can login
> to the system to do something, for example it should supervise a 
> supervisor, or at least supervise a getty. Otherwise the only way to 
> reboot a locked-in system is power-down.

The preceding seems to me to be exactly the argument of Laurent, author
of s6, when he rates s6 over runit. In runit (and Edward's PID1 with
s6 or runit), if someone kills PID2 and the supervisor and all the
gettys, PID1 spins happily forever, lovin life and listening to
nothing. The only means to retake control of the machine is powering
down.

My argument is that this very seldom happens in real life. You'd have
to try very hard to have this happen. I guess killall5 -9 would do it.

Needing to power down isn't the end of the world in most contexts. The
filesystem will require journal restoration and maybe fsck on the next
startup. Any non-transactional databases will be in an inconsistent
state. But this stuff happens all the time, for other reasons.

So my personal, and obviously your mileages do vary, priority is the
simplicity of a do-one-thing PID1, because the "PID1 alone in the
forest" happens so rarely, and at least in my situation the results
aren't earth shaking.

Didier's idea of PID1 supervising a single getty is an interesting
compromise, and of course that getty will have the advantage of being
an early getty.

SteveT

Steve Litt
June 2016 featured book: Troubleshooting: Why Bother?
http://www.troubleshooters.com/twb