Re: Customised control help

[KORN Andras <korn-supervise@elan.rulez.org>]

On Wed, Jan 02, 2008 at 06:44:53AM -0000, rehan khan wrote:

>    OK back to the bluetooth example. I had put the post start tasks in the
>    check script. I found that they were not being run when I rebooted the
>    machine but were being run if I did anything from the command line.
>    I guess this is because when runsvdir starts the service it just issues
>    an up command (no check script is run). I like the idea of the
>    bluetooth-postinit service but it breaks the compatibiltiy with init
>    that I need. Runit services need to exactly mirror what fedora init
>    looks like and be as self contained as an init script. I need this
>    mainly so that I can switch between init and runit services through a
>    (yet to be written) service management gui. It's a shame that runsvdir
>    can't be told to send a 'start' command instead of an up command. I

Since you want to do this the init way, you should include something like
"/etc/init.d/rc 2" (or maybe on Fedora it's "/etc/rc.d/init.d/rc 5"; use
whatever runlevel number used to be initdefault before you switched to
runit) in /etc/runit/1, and add a symlink to /usr/bin/sv from
/etc/init.d/bluetooth (or replace the initscript with a wrapper that calls
sv as appropriate).

Then the "rc" script will issue "bluetooth start".

I wouldn't say this is a good solution, but it would work and achieve
"self-containment". Personally, I don't see what's wrong with the
bluetooth-postinit service; it would still be fully compatible with init in
the sense that anyone expecting to use the initscripts to manage the service
would still be able to do so (they wouldn't ever have to concern themselves
with the bluetooth-postinit pseudoservice).

The only real downside I can see is that you'd waste a runsv process on it.

There is at least one other way you could try though: customise the "u"
command. Make it do something like this:

#!/bin/sh
exec 2>&1
(while ! chpst -L /var/lock/bluetooth-postinit.lock ./check; do sleep 1;
done) &
disown %1 # maybe this isn't needed, and maybe it's a bashism
exit 1

This is a pretty ugly hack as well, but it avoids the extra runsv process. I
haven't tried it, so it may not work, but I don't see why it shouldn't.

>    as it is the holiday period. I have one last issue that I see only
>    occasionally. I have every init daemon on my laptop using runit. They
>    are all started by runsvdir/runsvchdir. Very occasionally some critical
>    service does not start up during machine boot with the error 'runsv not
>    started'. I check for the existence of the service directory before
>    starting the service. I think runsvdir has not got to that particular
>    directory due to delays caused by the i/o frenzy during startup and the
>    fact that I do quite a lot of script processing (relatively) before
>    starting a service. This has become quite a big issue for me as I am
>    attempting to get some kind of LSB compatibility in my setup. So if a
>    'required-start' dependancy fails to start I have to shut it down.
>    Right now I am going to deal with that issue by adding a 'sleep' and
>    retrying if this error occurs. Is there a better way to avoid this

I'm not sure if I understand what it is you have to shut down when a
'required-start' dependency fails, but this is not the runit way of doing
things.

If service A depends on services B and C, and service C depends on service
D, then the run scripts should contain:

A/run:
#!/bin/sh
exec 2>&1
sv start B C || exit 1
[...]

C/run:
#!/bin/sh
exec 2>&1
sv start D || exit 1
[...]

This way, runit itself (runsv, to be precise) will periodically retry
starting all interdepending services and the dependencies will sort
themselves out automatically; that is, they will eventually start in the
right order.

Andras

-- 
                 Andras Korn <korn at chardonnay.math.bme.hu>
                 <http://chardonnay.math.bme.hu/~korn/>	QOTD:
                 RAM disk is *not* an installation procedure.