On Mon, Sep 29, 2014 at 8:06 PM, Alex Efros <[email protected]> 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...
