Supervising hardware-specific daemon with runit

[Denys Vlasenko]

On Friday 04 June 2010 17:15, Mikhail Gusarov wrote:
> Hello.
> 
> I've got a userspace daemon needed for functioning some piece of
> hardware, and interested in integrating it with runit (I suppose this is
> the best mailing list to discuss runit).
> 
> This daemon need to be started when the device is hotplugged (which may
> happen way before Stage 2) and stopped when device is ejected or system
> is shut down.

What is "stage 2"?

> Catching aforementioned events is easy, the hard part is how to start
> the service: you can't just enable service in /etc/service where Stage 2
> runsvdir looks, as daemon is needed before Stage 2.
> 
> The only idea I came up with which does not interfere with Stage 2
> runsvdir and allows daemon to be started early is
> 
> 1) separate runsvdir supervisor for "early services" is started at the
>    beginning of Stage 1.

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

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

If something has a dependency (e.g. "network must be up
before I start ntpd"), it's not really correct to fulfil
the dependency by artificially delaying its startup until
after network is up by sysinit script:
(1) what if DHCP server is down and therefore network
will be down for hours? ALL "stage 2" things will be down too?
(2) what if network WENT DOWN later, while ntpd is already running?
Say, ntpd exits in this case, runsv reastarts it... and now
it _has to_ deal correctly with the situation that network is down.
So, the run script must be able to handle it correctly anyway,
then what exactly we won bu delaying ntpd startup to "stage 2"?

> 2) Services are enabled/disabled in this "early services" directory
>    according to the devices hotplug/removal.
> 
> 3) Stage 3 shuts down both regular and early services.
> 
> This looks bulky, am I missing some obvious solution?

-- 
vda