On Fri, 17 Jun 2016 12:02:35 +0200 Didier Kryn <k...@in2p3.fr> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
