Supervising hardware-specific daemon with runit

Mikhail Gusarov dottedmag at dottedmag.net
Sun Jun 6 07:38:25 UTC 2010


Twas brillig at 08:37:07 06.06.2010 UTC+02 when vda.linux at googlemail.com did gyre and gimble:

 DV> What is "stage 2"?

That's from runit-init description, which as I see is not in busybox :)
Citing from runit site:

"stage 1" is one-time init
"stage 2" is regular operation
"stage 3" is halt/reboot

 >> 1) separate runsvdir supervisor for "early services" is started at
 >> the beginning of Stage 1.

 DV> Yes, it is not a crime to run many runsvdir's.

 DV> However, there's a question why can't you start the one you
 DV> currently start at "stage 2" (whatever that is) earlier?  On my
 DV> machine, I gradually moved most things under runsv[dir], even gdm
 DV> and gettys. My "pre-runsvdir" initialization is really minimal -
 DV> mounting /proc and such...

pre-runsvdir initialization might be much more complicated if storage
needs userspace helper daemons to operate (think of /home on NFS over
some weird WiFi card or userspace helper to decrypt partition -- not
real-life example, but something close to it).

 DV> If something has a dependency (e.g. "network must be up before I
 DV> start ntpd"), it's not really correct to fulfil the dependency by
 DV> artificially delaying its startup until after network is up by
 DV> sysinit script:

Yes, that's quite right, I didn't think about it before.

Though I have seen talks like "runit is for guaranteeing processes to
run, not for maintaining state" which sounds bad: how do I reliably
depend on "/dev/fb0 is available" which does not need to have process
running, but might be available asynchronously? It isn't elegant to have
pseudo-serivce which monitors the /dev for the said device.

-- 
  http://fossarchy.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20100606/a2043938/attachment.pgp>


More information about the busybox mailing list