Just a few notes on my journey into understanding runit... I went back and read some comments on the mailing list about udev, and the special issues it poses. I didn't read all of them because I had already run into the issue of "does it or does it not belong under runsvdir?". Eventually I was able to work around this by running udev in stage 1 by using the existing /etc/init.d/udevd script as a "hook", then shutting it down in stage 2 using the same "hook". This is far from perfect (for obvious reasons), but it worked enough to get me into running udevd under runsvdir in stage 2. In stage 3, the service from Stage 2 is automatically shut down, so I used the same "hook" to temporarily start it up again once services from Stage 2 are stopped, and then shut it down towards the end of the script.
This is hackery at its worst. It solves the problem in a temporary way but it isn't a real solution because it requires non-native tools to support it. I'm basically cheating. The issue remains - does udevd belong under Stage 2 service control? I gave this a bit more thought, and realized that the real issue isn't udevd. The issue isn't runit, or runsvdir, or the scheme that it uses. The issue really is that service control is a concept that is currently only in stage 2; it doesn't exist anywhere else. Now why can't it also be valid in stage 1 and stage 3? And then it hit me: runsvdir is about providing supervision of outward-facing services (by this I mean services that other services, other machines, or people will use), vs inward-facing services (services that are strictly for the system itself and not meant for consumption by a person, running service, or another machine). This is not a hard and fast definition, it is merely a description I'm making for lack of better words at the moment; please be patient with some of this vagueness and hand-waving. Getting 4 hours of sleep tends to do that... So, if runsvdir is about providing supervision for outward services, then how to we tackle inward services like udevd? I thought about doing the unthinkable - running a second runsvdir. And I had another thought - if you divide your service management into two groups, services that are internal only to the machine, and services for "everything else", then it would solve the entire problem. Services in stage 2 should not care about services in Stage 1 and Stage 3 necessarily. Stage 1 would start "internal" services and they would be caught and shut down in Stage 3. Stage 2 would simply "do its thing" and terminate in Stage 3 as well. If it is possible to get away with this, then some things that make life a little difficult, like running udevd under runit, go away, and nothing about the scheme that runit uses has to change at all - other than having two of runsvdir in your process table. So, is there anyone that has attempted to set up two running runsvdir process trees? Can it even be done? My impression - based solely on observation and not on documentation - is that runsvdir is probably a one-process deal, and that two of them would be asking for trouble.
