RE: /service vs /var/service vs /etc/service

["rehan khan" <rehan.khan@dsl.pipex.com>]

Hi all,

A very interesting discussion. I came across similar issues. The
standardised linux filesystem causes some issues in layout for runit
services where more configurability would come in handy.

Some points I would like to throw out for discussion are:

1) Although I have not extensively tested it I think SE Linux doesn't
get so easily fooled by all this sym linking. An application constrained
by SE Linux will be denied access to areas it is not allowed to access
by policy. So runit sevices might need to have additional policy to
support this. Having the service directories in /etc/init.d/service/NAME
kind of works around this issue as the service directories inherit
init's SE Linux policy  after a relabel but this doesn't really fix all
the potential problems. However this actually works out quite well as
SysV init utilises scripts and runit utilises directories and so
everything can fit into init.d or rc.d without causing too much
confusion. Recently SE Linux has been adopted by more distros and this
could become a more pressing issue (not just for Red Hat/Centos/Fedora
where it is enabled by default).

2) 'Shared memory' (on fedora /dev/shm - a tmpfs filesystem) might be a
good place to store the supervise directories as they are usually small
in size. They would also get erased on a reboot which is not such a big
issue as runit will re-create them. This would also alleviate a small
amount of disk i/o (==thrashing) during start-up. Not a big issue for
servers I guess but more important for desktop/laptop systems where
restarting is more common (at least until suspend/resume works out of
the box for more machines). The log directories would of course have to
point to a normal file system. This has the same issue as /var/run as it
will definitely get cleaned out on a reboot so the run script will have
to ensure that permissions are set correctly (which it should be doing
anyway to be robust).

So based on the above I would suggest a possible layout as follows:

(configuration) - /etc/rc.d/SERVICE NAME or /etc/rc.d/service/SERVICE
NAME for the service directories (or init.d instead of rc.d).

(working files) - /dev/shm/supervised/SERVICENAME

(logs) - /var/log/Service/SERVICE NAME or /var/log/SERVICE NAME


A couple of other things that would be nice to have (but off topic):

1) To enable runit to mirror more closely sysv init scripts that start
multiple processes. For example the nfs init script on Fedora starts
three or four services which together provide nfs. To mirror this as a
runit managed service one could use the main runsv to run a second runsv
as a service which started the same services but in a grouping of their
own. Right now if the secondary runsv is stopped (using sv stop) it
orphans the services or sv proceses it was supervising instead of
stopping them. 

This could be implemented as a runsv switch which tells runsv to send a
down command to all the services being managed and to wait until they
have all exited (report back as down) before stopping the sv processes
themselves and exiting itself. Using this, quite sophisticated service
management can be implemented without having to have a bunch of
additional related but separate service directories and the runit scheme
would more closely resemble the init scripts in that distro.

Another example would be the init script for vsftpd. This script
dynamically creates processes for each configured ftp site. To mirror
this I have a script which dynamically creates a service directory for
each ftp site and then runs runsv to start them. Stopping runsv does not
stop the vsftpd processes but orphans them. Being able to have runsv
tear everything down (sensibly), after being sent a term and before
exiting would make this just work.

2) It seems quite fashionable to connect things to the D-bus these days
and I am wondering if runit can leverage some of d-bus' functionality to
advertise services to the system or respond to service startup requests
over d-bus or at least provide notification of start/stop events. Of
course runit would have to start the d-bus service first :) I think I
have mentioned this before and it was shot down as over-complicating
things but it's still on my wish list.

3) A post-start script that sv runs if service X has been up for n
number of seconds. This could be implemented as an option to sv (e.g sv
-postart or sv -postart=n), as a shell variable or if a poststart
executable file exisis in the service directory then sv can just run it
an n number of seconds after the service has started (or been up, like
it does if the finish script exists). Although the number of seconds
should be variable depending on the speed of the machine a sensible
default could be used. As the original shell has been replaced by
execing the service this would necessarily need to be run in it's own
shell but sv would not have to supervise it, just run it assuming that
the service has started successfully if it has been up for n number of
seconds. This would be really useful. In fact a poststart script would
negate the need for a d-bus interface as the d-bus stuff could just be
done in the poststart (announces it is up) and finish scripts (announces
it is down).


Of course these things would be better demonstrated if I could produce
some code but C is a mystery to me. If there is some interest I could
probably do something in Python as a proof of concept to see if these
suggestions might be useful in the real world.


Cheers
rehan



-----Original Message-----
From: Robin Bowes [mailto:robin-lists@robinbowes.com] 
Sent: 19 April 2008 15:16
To: supervision@list.skarnet.org
Subject: Re: /service vs /var/service vs /etc/service

Gerrit Pape wrote:
> On Sat, Apr 19, 2008 at 02:35:43PM +0100, Robin Bowes wrote:
>> Gerrit Pape wrote:
>>> The Debian runit package now switched to /etc/service, and I'm about
to
>>> change runit to use /service by default, just as daemontools does.
>>> daemontools in Debian, just like runit in Debian, uses /etc/service,
and
>>> recommends to create a compatibility symlink /service ->
/etc/service.
>> Out of interest, where do you/Debian/others put the actual service  
>> directories, i.e. containing the run file and log dir? I currently
use  
>> /etc/sv/servicename and symlink to /var/service/
> 
> Me/Debian: /etc/sv/<service-name>, and the ./supervise symlinks point
to
> /var/lib/supervise/<service-name>[.log].  /var/run/ turned out to not
be
> appropriate, since it might be cleaned up on reboot, losing permission
> changes possibly made to the directory and files in it.

Thanks - that fits in with my gut feeling too (that /var/lib should be 
used rather than /var/run).

Where can I get the update-service script from? Would it be worth 
distributing that with runit?

R.