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 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, but you can use s6 exactly as you use daemontools - just add s6- prefixes to the daemontools command names and it will pretty much work the same. You can tell suckless init, or whatever pid 1 you fancy, to run s6-svscan, or runsvdir, exactly the same way you're telling it to run svscan. (The main difference is that daemontools comes with a svscanboot script that uses the "readproctitle" logging hack, and runit and s6 don't. As far as s6 is concerned: readproctitle felt too much like a cop-out to me, and I wanted a proper logging system for logs falling through s6-svscan's stderr, which is why I'm using a fifo as shown in the examples/s6-svscanboot script and the examples/ROOT/img/tmpfs/service/s6-svscan-log service directory.) Now, the thing is, when you have a process supervision system, it makes your stock init redundant. init has two jobs: A. 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. Process supervision systems automatically perform B, that's their very job; and svscan/runsvdir/s6-svscan automatically reap every zombie they get because they have to collect their dead supervisor processes. So they basically do everything init has to do in stage 2! It's then a natural idea to try and use them as pid 1. 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/ 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. 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. -- Laurent
