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
