The udev question & understanding what runsvdir "means"

From: Avery Payne <avery.p.payne_at_gmail.com>
Date: Mon, 29 Sep 2014 19:10:11 -0700

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.
Received on Tue Sep 30 2014 - 02:10:11 UTC