On Tue, 16 Jun 2015 09:29:15 +0200 Laurent Bercot <ska-supervis...@skarnet.org> wrote:
> On 16/06/2015 04:54, Steve Litt wrote: > > One thing I can tell you is that daemontools and daemontools-encore > > were never intended to be init systems, whereas I'm pretty sure that > > runit, s6 and nosh intended to be part or all of an init system. > > You keep saying that, but at least in the case of runit and s6, it > is inaccurate. > > runit and s6 are process supervision systems, just like daemontools, > and can be used with any init system. There are documentation pages > that prove it: > http://smarden.org/runit/useinit.html > http://skarnet.org/software/s6/s6-svscan-not-1.html Yes but: http://smarden.org/runit/replaceinit.html#sysv http://skarnet.org/software/s6/s6-svscan-1.html There's no way I've found to do init=/any/file/of/daemontools(-encore) > > That's one thing. When you say "s6 is more complex than > daemontools", it's only more complex because there are more binaries, > and more features, That's what I meant. s6 is a superset of daemontools, making it a little harder *for me, personally* to find my way around. Also, IIRC I couldn't compile s6 the last time, but the last time I knew nothing about the whole idea of init, so let me suspend saying it's more complicated until I've logged some time actually using s6. [snip] > Now, the thing is, when you have a process supervision system, it > makes your stock init redundant. init has two jobs: > A. reap zombies Do you include "listen for and handle relevant signals" in "reap zombies"? > B. maintain at least one other process alive, so that if everything > on the machine is killed (save init itself), it is still possible to > recover and avoid a hard and dirty reboot. > > Note that suckless init, or Rich Felker's suggested init in the > otherwise excellent http://ewontfix.com/14/ article, do not perform > B, and so, are *incorrect*. The error is minute, and probably > inconsequential in any real life situation, but it is still there; > and if you want the smallest possible pid 1 that will keep your > machine usable under the most dire circumstances, you should not use > suckless init, you should use runit. Yes. Someday I might change Suckless Init so that it *respawns* (supervises, whatever you want to call it) /bin/rc.init. I would also need a way that such a modified Suckless Init can pass along the information that this isn't the first time this boot, in case there are tasks I don't want to redo in /bin/rc.init. [snip] > And neither I > nor Gerrit did it first; the first one was Paul Jarc, who pioneered > the setup using... daemontools. http://code.dogmap.org/svscan-1/ I'd forgotten about that article. Last time I read it, I didn't understand it at all. This time, when I read it, it reminded me that my simple /bin/rc.shutdown stage 3 means I'm short circuiting the logs during final shutdown. > > Yes, daemontools was never intended to be an init system, but even > back then there was interest in running it as such, and Paul's > experiments are what started it all. > > The problem with init is that it's not only stage 2, and stage 1 > and 3 are heavily system-dependent; so making svscan work as init is > possible, but requires good hacking skills. Also, even after you get into stage 2, those "services" that do system initialization require hacking skills. > > Gerrit recognized that, so he basically forfeited the idea - > instead of using runsvdir as process 1, he created the minimal amount > of pid 1 code necessary to handle stages 1 and 3, as well as any > stage 2 (and runsvdir is the obvious choice for the stage 2 manager). > runit is a basic process supervision system (runsv/runsvdir) with a > simple init wrapper (runit). > > I did not want to give up on the idea; I designed s6-svscan so that > it would be easier to run as pid 1 than daemontools' svscan, and > managed to get something working reproducibly and in an almost > automatable way, but as you experienced, the setup still requires > some hacking skills, and I need more time to work around the > non-portability issues and come up with a full turnkey init. > > In the meantime, if you don't want to get your hands dirty, > you can still use s6-svscan/s6-supervise as a process supervision > system without trying to make it run as an init system, just as you > can use runsvdir/runsv as a process supervision system without using > the runit binary. That is real modularity, that is the main reason > why I believe runit and s6 are better designed than > other-init-software-out-there, and it would be *trivial* to port your > "suckless init on Plop" setup from daemontools(-encore) to runit or > s6, even if you don't use every feature those packages provide. I'll be doing an s6 install in the next few weeks. Thanks, SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key