Re: using runit as init

[Bernhard Graf <list-supervision@augensalat.de>]

On Thursday 10 January 2008 00:34, Mike Buland wrote:
> Regaurding service dependancies, Richard Gooch's method is actually
> unnecesarry in a sytem such as runit, and service dependancy is
> already handled in an almost identicle way, but with less system
> overhead.
>
> At the begining of a run script just start the services you depend
> on, and exit if the sv command returns non-zero.  I.e. from hal's run
> script: sv start /etc/service/dbus || exit 1

I tend to object:

You mean starting a bunch of programs over and over again, because many
of them quit immediatly is less system overhead than starting programs
that pause until those programs they depend on are started?

Also imagine one service A that depends on service B, C and D. You have
to put the checks for availability of B, C, D into A's run script.
In a complex system more services depend on B, C and D and probably
others. You have to put the same checks (and others) in all those
services. Also those checks tend to be more complicated than just saying
"need B C D".

> As far as running SysV init style scripts, usually handled on modern
> linux systems (redhat, slackware, debian, etc) by the master rc
> script, are you suggesting that rc, to control runlevel changes be
> placed in it's own service, or that each SysV "service" gets it's own
> runit service?

The latter.

> If you're referring to the later case, you'll need to do a lot more
> work to synchronize the rc scripts and the runit services, I can't
> imagine how just making symlinks between the init.d runlevel
> directories and runsvdir service directories will actually work.

In current distributions (hopefully) an init.d script is configured
using a program that sets the appropriate symlinks. The information for
run levels and dependencies are taken from the init scripts [5], [6].

If you'd replace init by runit, you had to replace those installtion
programs as well.

This installer would install the example from [5] as:

# ls -l /etc/runit/sv/lsb-ourdb
-rw-------   1 root root      0 Jan 10 09:00 initd
-rw-------   1 root root     30 Jan 10 09:00 need
lrwxrwxrwx   1 root root     19 Jan 10 09:00 run -> /etc/init.d/lsb-ourdb
# cat /etc/runit/sv/lsb-ourdb/need
$local_fs
$network
$remote_fs
# ls -l /etc/runit/runsvdir/2/lsb-ourdb
lrwxrwxrwx   1 root root     19 Jan 10 09:00 /etc/runit/runsvdir/2/lsb-ourdb -> /etc/runit/sv/lsb-ourdb
# ls -l /etc/runit/runsvdir/3/lsb-ourdb
lrwxrwxrwx   1 root root     19 Jan 10 09:00 /etc/runit/runsvdir/3/lsb-ourdb -> /etc/runit/sv/lsb-ourdb
# ls -l /etc/runit/runsvdir/4/lsb-ourdb
lrwxrwxrwx   1 root root     19 Jan 10 09:00 /etc/runit/runsvdir/4/lsb-ourdb -> /etc/runit/sv/lsb-ourdb
# ls -l /etc/runit/runsvdir/5/lsb-ourdb
lrwxrwxrwx   1 root root     19 Jan 10 09:00 /etc/runit/runsvdir/5/lsb-ourdb -> /etc/runit/sv/lsb-ourdb

File initd is a flag for runit to run the script with argument "start"
first, then wait for SIGINT and run the script with argument "stop".

File need contains services that runit has to be started first.
"$service" for "meta services" as set with "provide" in Gooch's concept.

> Finally, if you really do want to start an rc script and make it
> appear as though it were a normal runit system service, then I would
> reccomend starting it in a run script, then executing a command that
> blocks forever.  The service will use effectively no CPU time, but
> will stay running, forever. Then you can call the corrisponding rc 6
> or whatever you want in the finish script of the service.

I will try this, and see how far I get...


[5] http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html
[6] http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html

-- 
Bernhard Graf