runsv and runsvdir problems

runsv and runsvdir problems

[Ciprian Dorin Craciun]

    Hello all!

    First of all I must say I like the runit suite very much, and for
about half a year I use it to manage almost all my services (normal
ones and personal ones) on my laptop.

    Usually it runs smoothly, without any big problems, with a few exceptions:
    * first of all I use runsvdir for all the system services (like
udev, getty, etc.);
    * also I allow each user (my self for now) to have a special
service that runs another runsvdir;
    * as my services I use anything, from the X server and client,
bittorent client, to the music player;

    Something like
    -- runsvdir /services
      \-- runsv /services/udev
      \-- runsv /services/getty-1
      ...
      \-- runsv -> runsvdir /services/ciprian
        \-- runsv x
        \-- runsv vpn
        \-- ...

    But there are a couple of problems with this setup (so I propose
some feature requests):

    * first of all a lot of services are not started by default (by
using the 'down' file), but this doesn't stop runsv to start the
logger => could there be an option to start the loggers only when the
server actually starts?

    * if I send HUP to runsvdir /services it sends TERM to runsv
/services/ciprian, which in turn sends TERM to runsvdir
/services/ciprian which breaks, and leaves all my services dangling...
=> could there be an option to actually pass the same signal down the
chain? (for example if I send TERM to runsv or runsvdir, it should
send TERM downpath, and so for any other signal, for example USR1,
etc.)

    * if I want to stop the runsvdir /services it sends the signal to
all its children, but exists immediatly, and this is a problem if I
stop it from an rc.0 or 6 script, because it should wait for all the
children to actually stop; for now it leaves them dangling, and the
unmounting of the file systems breaks... => could there be an option
to actually make runsvdir to wait for it's children?

    * if a process takes to long to terminate (when it receives TERM
signal), it would be nice for runsv to actually send KILL, but this
should be configurable, as I wouldn't like to have runsv kill runsvdir
like this;

    * (a small annoyance) it would be nice to be able to combine runsv
and runsvdir into a single command, as this would reduce the number of
runsv processes, until I actually need to start a service;

    So I repeat that runit suite is a very good one, but I would be
very happy to see these problems solved.

    Thanks all, and keep up the good work,
    Ciprian Dorin Craciun.

Re: runsv and runsvdir problems

[Alex Efros]

Hi!

On Mon, Oct 27, 2008 at 07:12:21PM +0200, Ciprian Dorin Craciun wrote:
>     * first of all a lot of services are not started by default (by
> using the 'down' file), but this doesn't stop runsv to start the
> logger => could there be an option to start the loggers only when the
> server actually starts?

why starting these loggers bother you? they doesn't hurt anything

>     * if I send HUP to runsvdir /services it sends TERM to runsv
> /services/ciprian, which in turn sends TERM to runsvdir
> /services/ciprian which breaks, and leaves all my services dangling...
> => could there be an option to actually pass the same signal down the
> chain? (for example if I send TERM to runsv or runsvdir, it should
> send TERM downpath, and so for any other signal, for example USR1,
> etc.)

you can configure this behaviour - check CUSTOMIZE CONTROL in runsv(8)

>     * if I want to stop the runsvdir /services it sends the signal to
> all its children, but exists immediatly, and this is a problem if I
> stop it from an rc.0 or 6 script, because it should wait for all the
> children to actually stop; for now it leaves them dangling, and the
> unmounting of the file systems breaks... => could there be an option
> to actually make runsvdir to wait for it's children?
> 
>     * if a process takes to long to terminate (when it receives TERM
> signal), it would be nice for runsv to actually send KILL, but this
> should be configurable, as I wouldn't like to have runsv kill runsvdir
> like this;
 
I usually do this:

    # Give a chance for all processes for clean exit.
    # This also will kill all 'runsvdir' and signal all 'runsv' to exit.
    killall5 -15

    # ... some other de-initialization like hwclock --systohc

    sv force-stop /var/service/* &>/dev/null || :

    # ... more things to do while services stopping - save sound mixer
    # state, remember last random, shutdown network interfaces, etc.

    # Goodbye to everybody...
    killall5 -9

    # unmount and reboot

>     * (a small annoyance) it would be nice to be able to combine runsv
> and runsvdir into a single command, as this would reduce the number of
> runsv processes, until I actually need to start a service;

why starting these processes bother you? they doesn't hurt anything too

really, having small annoyance each time you do `ps` and see a lot of
small processes which do nothing useful except keeping all your system
services running in reliable way - is fairly acceptable. and you always
know how to run all your services in less reliable way with standard
/etc/rc.d/* scripts to avoid this annoyance

-- 
			WBR, Alex.

Re: runsv and runsvdir problems

[Ciprian Dorin Craciun]

On Mon, Oct 27, 2008 at 7:30 PM, Alex Efros <powerman@powerman.name> wrote:
> Hi!
>
> On Mon, Oct 27, 2008 at 07:12:21PM +0200, Ciprian Dorin Craciun wrote:
>>     * first of all a lot of services are not started by default (by
>> using the 'down' file), but this doesn't stop runsv to start the
>> logger => could there be an option to start the loggers only when the
>> server actually starts?
>
> why starting these loggers bother you? they doesn't hurt anything

    It does not bother me too much, except the fact that there are
processes running, which do not do anything... And I usually like to
keep a small number of active processes... (This also applies to the
last question.)


>>     * if I send HUP to runsvdir /services it sends TERM to runsv
>> /services/ciprian, which in turn sends TERM to runsvdir
>> /services/ciprian which breaks, and leaves all my services dangling...
>> => could there be an option to actually pass the same signal down the
>> chain? (for example if I send TERM to runsv or runsvdir, it should
>> send TERM downpath, and so for any other signal, for example USR1,
>> etc.)
>
> you can configure this behaviour - check CUSTOMIZE CONTROL in runsv(8)

    I know about this settings, and this is how I do it (with an x
file in the control folder)... But the problem is that the signal
interface (if I can call it so) to the runsv and runsvdir are
incompatible even though they should be used together... So I say that
this is more a design issue...

    Also, as I said, it would be nice to have all the signals being
passed down the hierarchy -- imagine I would like to implement with
USR1 signal the functionality to reload all configuration files for
all the services (where applicable). Also going a step further, maybe
it would be nice to have custom signal handlers inside control folder
(like usr1, alrm, just like normal command characters);


>>     * if I want to stop the runsvdir /services it sends the signal to
>> all its children, but exists immediatly, and this is a problem if I
>> stop it from an rc.0 or 6 script, because it should wait for all the
>> children to actually stop; for now it leaves them dangling, and the
>> unmounting of the file systems breaks... => could there be an option
>> to actually make runsvdir to wait for it's children?
>>
>>     * if a process takes to long to terminate (when it receives TERM
>> signal), it would be nice for runsv to actually send KILL, but this
>> should be configurable, as I wouldn't like to have runsv kill runsvdir
>> like this;
>
> I usually do this:
>
>    # Give a chance for all processes for clean exit.
>    # This also will kill all 'runsvdir' and signal all 'runsv' to exit.
>    killall5 -15
>
>    # ... some other de-initialization like hwclock --systohc
>
>    sv force-stop /var/service/* &>/dev/null || :
>
>    # ... more things to do while services stopping - save sound mixer
>    # state, remember last random, shutdown network interfaces, etc.
>
>    # Goodbye to everybody...
>    killall5 -9
>
>    # unmount and reboot

    This could be a solution too, but it doesn't run out of the box...
When I wanted to use runit, I had to spend a lot of time to tackle
exactly these issues... So I would say it leads to a deployment
problem...

    I ended up using a similar solution:
    kill -s HUP "${pid}"
    sleep 3
    killall -q -s TERM runsv runsvdir
    sleep 3
    kill -s KILL "${pid}"
    killall -q -s KILL runsv runsvdir

    But this seems like a hack to me...


>>     * (a small annoyance) it would be nice to be able to combine runsv
>> and runsvdir into a single command, as this would reduce the number of
>> runsv processes, until I actually need to start a service;
>
> why starting these processes bother you? they doesn't hurt anything too
>
> really, having small annoyance each time you do `ps` and see a lot of
> small processes which do nothing useful except keeping all your system
> services running in reliable way - is fairly acceptable. and you always
> know how to run all your services in less reliable way with standard
> /etc/rc.d/* scripts to avoid this annoyance

    I agree with you that it is much eassier to manage the services by
using runit than the sys-v5 way of doing things, but what I am saying,
is that there is just another small step to be taken in order to
obtain a complete solution...

    The ultimate step would be to integrate somehow service
dependencies in the entire design... Maybe a initialize script, that
if it exits, it will not continue with the run script. I know that i
could do this directly inside the run file, but so could we have done
with the case of finish...

> --
>                        WBR, Alex.

    Thank you for your feedback,
    Ciprian Craciun.