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
> 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.
Why are you doing this? I'm just run udev in /etc/runit/1 and forget about it:
echo "" >/proc/sys/kernel/hotplug
[ -x /sbin/udevd ] && udevd=/sbin/udevd || udevd=/lib/systemd/systemd-udevd
$udevd --daemon
udevadm trigger --type=subsystems --action=add
udevadm trigger --type=devices --action=add
udevadm settle --timeout=30
It will be killed with all other processes using killall5 in /etc/runit/3.
Only problem I've with this scheme is ugly way to restart udev after
updates, which I'm currently doing manually this way:
killall udevd ; grep udev /etc/runit/1 | sh
> 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.
> 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 - one is running system services and others are started by usual
users from cron (it's possible to start then from system services, but
using cron result in providing ability for users to use runsvdir without
asking root to create new system service for them - also this works on
servers where user won't have neither root nor runit and have to compile
runit in home dir).
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.
So, you probably can start runsvdir at stage 1, but… who will supervise it?
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).
Next, /etc/runit/1 is synchronous, while services are not. So, if you'll
try to move parts of /etc/runit/1 tasks into runsvdir-started services
you'll have to start most of them in order or use some way to implement
dependencies (this can be easily done for runit with help of few simple
shell scripts, but, anyway, it makes system more complicated).
--
WBR, Alex.
Received on Tue Sep 30 2014 - 03:06:52 UTC