On Mon, Sep 29, 2014 at 8:06 PM, Alex Efros <powerman_at_powerman.name> wrote:
> Hi!
>
> On Mon, Sep 29, 2014 at 07:10:11PM -0700, Avery Payne wrote:
> > 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
>
> Why are you doing this? I'm just run udev in /etc/runit/1 and forget about
> it:
>
Part of my goal is to have good integration with Debian's environment.
SysV init scripts are still available, for the moment, in the environment
I'm using. Also, Debian has an unfortunate dependency on
/etc/init.d/(script) being present. During the update process with
apt-get, you will see services stop and restart, and it does so by calling
init.d scripts. The hooks for restarting services during the update have
no concept of services controlled elsewhere.
Runit does provide a shunt for intercepting SysV init.d scripts, so.... my
goals are (a) try to get some minimal integration with init.d scripts so
that apt-get update continues to work seamlessly, and (b) as I explained in
the original message, using the existing init.d script was a horrible hack
to begin with, done for the sake of expediency.
Only problem I've with this scheme is ugly way to restart udev after
> updates, which I'm currently doing manually this way:
>
Which is precisely why I am looking at how to get it managed, rather than
doing init.d scripts or manual restarts.
> > 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
>
> That's an interesting idea, but I doubt it's true and/or important.
> Several services started on stage 2 can be named inward-facing, using your
> words: socklog-klog, socklog-unix, mcelog… probably even acpid and smartd.
> All works perfectly at stage 2, and only udev is so… special.
>
Ah, now that I've had a good night's sleep, I can clearly explain things.
First, socklog-*, syslog, acpid, smartd, are all "outward" services in my
definition, because something or someone, somewhere, can call upon them
(send input), or consume their service (receive output). udevd is special,
true, but to my knowledge, only the kernel really toys with it (or at least
in theory). It wasn't *meant* to send input or output elsewhere, even
though it *can*.
What I was trying to explain was that runsvdir runs inside of a context.
In this case, the context of stage 2 is "services that are called by other
services or users". udevd doesn't fit well into that context, which is why
I am looking at running it "outside" of the runsvdir that occurs in stage
2. So, my solution was "let's try to find a way to set up a separate
context - a 'system' context - and place udevd inside of it". So there is
a context for services that are meant to be inward facing (udev), and a
context for services meant to be outward facing (everything else). Mixing
the two contexts together is why udev looks awkward when trying to control
and implement it in stage 2.
> > 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.
>
> No, it won't. I'm running a lot of runsvdir processed on same system for
> years (snipped text...)
>
I have an unfortunate habit - after writing a long message with a question,
and sending it, I usually think of the solution 1-2 hours later. My
apologies in advance...
It occurred to me that if you can get user-specific runsvdir instances to
be managed, then I might be able to make the stage 2 just another instance,
and launch runsvdir early (along with udev) in stage 1. So when stage 2
rolls around, the rest of the services start up under a runsvdir that is
itself under the runsvdir that occured in stage 1.
Basically, after seeing the other message from Laurent, it looks like I'm
re-doing the s6 startup sequence inside of runit itself.
> The only problem with other runsvdir processes is who will supervise them?
> The "main" runsvdir is supervised by runit (pid 1) itself and if it dies
> runit will switch to stage 3.
>
As you and others have pointed out, this is a problem. So even if I
replaced the execution of runsvdir in stage 2 with a symlink in /service
that starts it, the script will continue and exit - resulting in the system
shutting down. Too bad there wasn't a way to get the script to pause
as-is. Of course, pausing a script is also an ongoing problem with some
run scripts that emulate running services (such as loading iptables into
memory), but actually exit the run script, resulting in the runsv looping
the run script over and over. Runit really, really needs a pause(1)
command to assist with this. Apple supposedly has a snippet of code
floating around that might do the job (and it's named "pause.c"), but I
think it is copyrighted by them.
> So, you probably can start runsvdir at stage 1, but… who will supervise it?
>
If runsvdir exits then there are bigger problems. Init won't restart it
and as you pointed out it will start shutting down the system, taking this
as a sign that it's time to power off. Because there isn't real oversight
of it to begin with, I'm not entirely sure that supervising runsvdir is an
issue. And if it is non-issue, then we should be able to do this, and it's
just a matter of cleaning up after the stage 1 runsvdir inside of stage 3.
> Also, udev is usually started very-very early, even before remounting root
> fs read-write. And I'm not sure runsv is able to start udev service on
> read-only fs (we probably can work around this by copying udev service
> directory into tmpfs-mounted location, like /run, which usually already
> available at this point).
>
Most startup scripts "cheat", and run udev directly so that it will
populate /dev. When run in this context, udev is meant to be a one-shot
deal, just starting up long enough to map out devices. So this might also
be a non-issue.
> Next, /etc/runit/1 is synchronous, while services are not.
>
True. The real issue is, if you start udev under runsv under runsvdir in
stage 1, your stage 1 script will need to wait for udev to finish before it
can proceed. If you can do this (as mentioned above), then again, it's a
non-issue. How is this done currently with init.d scripts? I know Debian
is doing something to pause execution while udev populates /dev...
Received on Tue Sep 30 2014 - 18:28:08 UTC