RE: using runit as init

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

Starting services over and over seems odd to me too. Unfortunately I
have come to believe that this is unavoidable in any supervision system
without getting every project/programmer of every app that needs an init
script to put in some code to support a 'wait/pause' feature. Of course
this will never happen. Getting runit to do it will bloat runit beyond
any usefulness.

I don't believe runit is a good replacement for init because it does not
solve all the challenges an init system may need to overcome. However
the things that it does do it does really well. So it is a good add-on
to SysV init. IMHO it is a great adjunct to any existing init and using
both together provides one with an environment that is 100% backwards
compatible, whilst providing service supervision and parallel startup. I
can't see any compelling reasons to replace init with runit except for
special cases like memory constrained systems using a dietlibc compiled
runit.

Many techniques have been discussed recently on the list to run services
once or to wedge system init scripts into a runit environment but they
are workarounds at best or kludges at worst. The best idea is to not use
runit for these tasks and to continue to use init. This will save you
lots of time trying to resolve issues that don't really need to be
resolved (they are taken care of quite well by init). The only downside
AFAIKS is that you don't get any benefit from parallelisation. On a
server system this is not too great an issue but on desktop systems it
is more of an issue.

D-bus and haldaemon are getting a strong following especially in the
Gnome world and these services tend to develop dependencies built upon
them. e.g. Bluetooth, avahi, yum-updatesd, bind and others depend on
d-bus and sometimes also haldaemon through d-bus on Fedora. D-bus dying
breaks all these other services and re-starting d-bus does not fix them
(they don't re-attach to d-bus automatically). They all have to be
stopped and restarted. This is where runit falls down if you have a
default installation or use execline based scripts. A runit environment
needs to be wrapped in some other environment that takes proper care of
dependancies (not just start-up ones but stop/restart dependancies as
well) and other caretaking tasks.

[ btw, d-bus is a very stable app and has not crashed in my experience
so no disrespect to the d-bus developers :) ]

I have come up with some of this wrapper code in the fedorafastboot
project. So when a service starts up, it 'registers' itself with any
dependancies it starts. If those dependancies stop for any reason their
finish script stops the dependant services as well (there is no
mechanism in runit to do this). What has still not been done is a proper
restart. When d-bus stops and the dependant services also stop only
d-bus gets restarted not the dependant services (which ideally should
also be restarted). It's all very messy and overly complicated but
eventually I will have all this covered somehow, hopefully in a
user-transparent way where the user only has to specify the dependancies
in the run script and the wrapper code does all the rest of the work.

Still, I have it working in a useful way right now where if d-bus stops
or crashes it will pull down any services that depend on it as well. A
ctrl-alt-backspace restarts X and as X is also a supervised with a list
of dependancies it restarts all the dependancies and restarts X (plus
all the panel applets which depend on those services). Still a bit kooky
but it does not require a reboot, just an X restart.

Init still runs the iptables scripts, kudzu, wine and a couple of other
(non-daemon) scripts which won't benefit from being managed by runit.

Perhaps what would be most beneficial for runit long term would be to
add runit's service supervision functionality natively into InitNG
and/or Upstart.

R


-----Original Message-----
From: Bernhard Graf [mailto:list-supervision@augensalat.de] 
Sent: 10 January 2008 09:31
To: supervision@list.skarnet.org
Subject: Re: using runit as init

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