Customised control help

Customised control help

[Rehan Khan]

Hi

From the man page for runsv:

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)

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 
everything a term signal should do?)? Right now the services don't stop 
properly and the status command reports 'run, want down' and the service stays 
up without exiting.

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)

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

Thanks in advance
R

Re: Customised control help

[KORN Andras]

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.

Re: Customised control help

[Charlie Brady]

On Tue, 1 Jan 2008, Rehan Khan wrote:

> From the man page for runsv:
>
> Customize Control
> For each control character c sent to the control pipe, runsv first checks if
...
> 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, that's what the "for each" means :-)

> 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
> everything a term signal should do?)?

If your custom control script exits non-zero, then runsv will send the 
term signal. If your custom script exits zero, runsv will do nothing. You 
therefore have two choices for sending the term signal - do it yourself in 
the custom script, or allow runsv to do it by exiting non-zero.

> Right now the services don't stop properly and the status command 
> reports 'run, want down' and the service stays up without exiting.

So you have to fix the service, or do something other than send a term 
signal to terminate the service.

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

I think the man page of runsv is complete and accurate. What do you think 
is missing? The source code might help you if you wish to learn more or to 
confirm what you read in the man page.

RE: Customised control help

[rehan khan]

[-- Attachment #1: Type: text/plain, Size: 3251 bytes --]

Charlie Brady <charlieb-supervision <at> budge.apana.org.au> writes:

> 
> Yes, that's what the "for each" means 
> 
> 
> > 4) Is there a more detailed description of customised control somewhere?
> 
> I think the man page of runsv is complete and accurate. What do you think 
> is missing? The source code might help you if you wish to learn more or to 
> confirm what you read in the man page.


Heh, some of my questions might seem dumb but I have read ALL the docs many
times over. I have found the documentation to be 100% complete. However
sometimes it can be difficult to interpret for all situations (or the particular
situation that is in my head :). For example in the above documentation example
it might be better to say that the examples given are special cases or that they
are examples that apply to all the options. Perhaps also to expand on the
description and to describe the exit codes (even if it is repeated from elsewhere).


> So you have to fix the service, or do something other than send a term 
> signal to terminate the service.

Regarding the t script, I used this :

[ -r ../supervise/pid ] && PID=`cat ../supervise/pid` && kill "$PID"

To term the the process but I think the other methods (setting exit codes etc)
require less processing so I'll switch to those.

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 want to keep things as simple
as possible so that other people might choose to write runit services as well as
an init script.

I really appreciate you guys taking the time to answer my questions especially
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 issue?

Thanks
Rehan

[-- Attachment #2: Type: text/html, Size: 3951 bytes --]

Re: Customised control help

[KORN Andras]

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.

RE: Customised control help

[Charlie Brady]

On Wed, 2 Jan 2008, rehan khan wrote:

>>> 4) Is there a more detailed description of customised control somewhere?
>>
>> I think the man page of runsv is complete and accurate. What do you think
>> is missing? The source code might help you if you wish to learn more or to
>> confirm what you read in the man page.
>
> Heh, some of my questions might seem dumb but I have read ALL the docs many
> times over. I have found the documentation to be 100% complete. However
> sometimes it can be difficult to interpret for all situations (or the particular
> situation that is in my head :). For example in the above documentation example
> it might be better to say that the examples given are special cases or that they
> are examples that apply to all the options.

I think it reads clearly that 'o', 'd' and 'x' are special cases, and that 
'for each' really does mean 'for each', but YMMV.

> Perhaps also to expand on the description ...

How would the description be expanded if it is already complete?

> and to describe the exit codes 
> (even if it is repeated from elsewhere).

The exit codes of runsv are clearly stated. The interpretation of zero 
exit status from custom control scripts also seems clearly stated to me.

  "If the program exits with return code 0, runsv refrains from sending the
   service the corresponding signal."

What would you express differently?

RE: Customised control help

[rehan khan]

[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]

:( Don't let my confusion upset you so. I'm just not an expert on these things and there is a lot to take in.

I think that the following section makes it a little confusing

'before interpreting the command. If the program exits with return code 0'

It might be a little clearer, language-wise, if the text stays with using script instead of using command and program interchangeably with script (they are different, are they not?). Separating out the exceptions would also highlight them. So the text would be something like:

Customise 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 result (return code) of the script. If the script exits with return code 0, runsv refrains from sending the service the corresponding signal. If the script exits with a return code greater than 0 the corresponding signal is sent to the service.

Notes for Customised Control:
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.


[-- Attachment #2: Type: text/html, Size: 1761 bytes --]

RE: Customised control help

[Charlie Brady]

On Wed, 2 Jan 2008, rehan khan wrote:

> :( Don't let my confusion upset you so. I'm just not an expert on these things and there is a lot to take in.
>
> I think that the following section makes it a little confusing
>
> 'before interpreting the command. If the program exits with return code 0'
>
> It might be a little clearer, language-wise, if the text stays with 
> using script instead of using command and program interchangeably with 
> script (they are different, are they not?).

'script' is a subset of program. 'scripts' are programs, but not all 
'programs' are scripts. 'command' is a one byte character written into the 
control fifo.

> Separating out the exceptions would also highlight them. So the text 
> would be something like:
>
> Customise 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 
> result (return code) of the script.

Reference here to 'script' is incorrect. service/control/c is a program 
(and only might be a script).

I think it would be better to just end the sentence with "and waits for it 
to terminate". The existing "before interpreting the command" appears to 
be confusing, and "before interpreting the result (return code) of the 
script" may also be confusing. At any rate it is an unnnecessary phrase, 
as "If the script exits with return code 0" most definitely implies that 
runsv interprets the return code.

> If the script exits with return code 0, runsv refrains from sending the 
> service the corresponding signal. If the script exits with a return code 
> greater than 0 the corresponding signal is sent to the service.

You are assuming that return codes are not less than zero.

> Notes for Customised Control:
> 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 wonder whether it would make things clearer if the sections Control and 
Customize Control were combined. viz:

Control

The named pipes service/supervise/control, and (optionally) 
service/log/supervise/control are provided to give commands to runsv. You 
can use sv(8) to control the service or just write one of the following 
characters to the named pipe:

...
d
     Down. If the service is not running, do nothing. If ./control/t
     exists, and is executable, execute it and wait for it to terminate.
     If ./control/t does not exist, but ./service/control/d exists and
     is executable, execute it and wait for it to terminate. If neither
     program exists, or the program exits with non-zero status, then
     send the service a TERM signal, and then a CONT signal. If ./run
     exits, start ./finish if it exists. After it stops, do not restart
     service.
...

RE: Customised control help

[rehan khan]

[-- Attachment #1: Type: text/plain, Size: 290 bytes --]


I think merging the control and customised control sections would only make things more confusing. There is just too much information. The current separation is ok, just the customised control section could use more clarity. The information is there it's just difficult to extract.

R

[-- Attachment #2: Type: text/html, Size: 670 bytes --]