Re: Customised control help

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

On Tue, Jan 01, 2008 at 08:27:34AM +0000, Rehan Khan wrote:

Hi,

> Customize Control
>  For each control character c sent to the control pipe, runsv first checks if 
> service/control/c exists and is executable. If so, it starts service/control/c 
> and waits for it to terminate, before interpreting the command. If the program 
> exits with return code 0, runsv refrains from sending the service the 
> corresponding signal. The command o is always considered as command u. On 
> command d first service/control/t is checked, and then service/control/d. On 
> command x first service/control/t is checked, and then service/control/x. The 
> control of the optional log service cannot be customized.
> 
> I have a couple of questions:
> 
> 1) are all the control codes supported? Not just the ones in the above 
> paragraph? (h, 1, 2, etc)

Yes.

> 2) I have the t script for some of my services. Do I have to send a term 
> manually after I have run the pre-term commands I need (i.e do I have to do 

No. Just make sure your script exits with a nonzero exit status.

> 3) (Not directly related to the above.). I have a service called bluetooth 
> which starts up the hcid process. The normal fedora init script runs some 
> commands after the hcid daemon starts (using hciattach command). If the 
> service starts successfully how can I run these post start commands within the 
> runit method instead of in a separate script. I would like to keep everything 
> a service does in the service directory. (I could background and disown 
> another script with a sleep pre-pended but this is not a particularly clean 
> implementation)

Depending on what exactly those post-commands are, you could put them in a
'check' script; sv start would invoke that repeatedly until it exits
successfully or until it times out. Make sure the script is idempotent and
that it doesn't screw anything up badly if it's invoked when hcid is down.

I think it would be better to write a new service called e.g.
'bluetooth-postinit' or something, make it 'normally down' (i.e. 'touch
./down') and make its run script do something like this:

#!/bin/sh
exec 2>&1
sv start bluetooth || exit 1
#
# post-commands go here
#
exec sv down .

The bluetooth run script should then do:

[...]
sv up bluetooth-postinit
exec chpst [args] hcid [args]

And if hcid isn't necessarily 'up' just because it's running, also write a
'check' script for the 'bluetooth' service that exits successfully IIF hcid
is ready.

> 4) Is there a more detailed description of customised control somewhere? 

Not that I know of.

Andras

-- 
                 Andras Korn <korn at chardonnay.math.bme.hu>
                 <http://chardonnay.math.bme.hu/~korn/>	QOTD:
              Life is much easier if you look at the source code.