One of the things I've been doing with Runit on my end is moving more and more hopefully into Stage-2 for supervisory purposes.
Now granted some things are not able to be supervised such as udev on my end. But honestly, does udev really require supervision? That's not an easy question to answer, but it does propose the idea that sometimes there are one-shot daemons that do not need supervision, they need to be ran, and just left alone. While the pause applet I use keeps a few daemons in a holding state, there are sometimes I have to wonder if everything requires supervision, and the answer is no. While I can move a lot of services into supervisory mode in Stage 2, there are benefits of the stage-1 one-shot. Less to supervise, less that needs to be rerouted through a holding state, and more focus on true services. The Runit script I'm going to publish soon, when I get my new updated script set revised and redrafted, is going to move a lot more into stage-2, but ironically, it's very little as most things were already moved into Stage-2 a while ago. Stage-1's purpose is basically to mount file systems, load drivers, check the file system, and load the disks. Now first off, yes, I could move udev into stage-2, but there-in lies an issue, what would then require a redrafting of many service scripts to check for udev, then load? Udev in my opinion is a one-shot daemon. It loads devices and it settles, and that's it. DBus already has many services check for it. If we expand this it only increases the complexity factor, so that's why things get moved around from stage-2 to stage-1, unless otherwise shown to be necessary. Stage-2's purpose should monitor and supervise all other services, in my opinion, log output as needed, and load and check daemons and dependencies as needed. > Date: Wed, 23 Jul 2014 22:18:26 +0100 > From: [email protected] > To: [email protected] > Subject: Re: initialization vs supervision > > On 23/07/2014 20:16, Wayne Marshall wrote: > > In the best of un!x traditions, a stronger > > system may in fact be one that recognizes the fundamental > > differences between the two functions, and provides purpose-specific > > solutions for each of them. > > I absolutely agree with this, as with all the rest of your message. > > However, an initialization system can strongly benefit from being > tailored to use a supervision system, so close ties between the two are > not surprising. > Doing all the one-time initialization without having supervision > support is complex: one-time initialization often needs early services, > that the rest of the initialization depends on - I think of a default > logger, and of udevd, for instance. > The pstrees that are posted in this thread show a nice amount of > supervised services, and also some services that are *not* supervised; > the reason for this is probably that the unsupervised services are > started in /etc/runit/1, when runsvdir isn't yet started. This is a shame: > you want core services to be supervised, even more than non-core ones. > > I believe the right way for an initialization system to boot is: > - do the minimum necessary amount of early init so the supervisor can work > - fork the one-time initialization process, and block it so it can only > run once the supervision tree is active > - exec into the supervision system (so that it is either process 1 itself, > or supervised by process 1). > > This is the approach I have with s6. However, since I wanted to keep s6 > system-agnostic and, as you said, initialization is system-dependent, I did > not provide an out-of-the-box /sbin/init - and it put too much work in the > hands of packagers. I intend to work on a s6-init package, which will > unfortunately have to be Linux-specific, to cover this flaw. The forked > one-time initialization process can safely be left to distribution packagers, > just like /etc/runit/1 is; but the tricky /sbin/init has to be provided in > order for an integrated init+supervision system to be usable. > > -- > Laurent >
