Re: using runit as init

[Mike Buland <mike@geekgene.com>]

On Thursday 10 January 2008 02:20:51 am Bernhard Graf wrote:
> 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".

I'm honestly not sure how your need solution covers these mysterious more 
complicated, but you're just using need in your example below, so...

Anyway, need will not block forever, it needs to do a number of different 
things periodically to ensure that the service has not gone into an 
unexpected state, etc, etc.  Starting a script once every seven seconds, as I 
mentioned, or at a larger interval, as you suggested, I do not feel is 
significant system overhead.  If you're using bash, bash will be using about 
2 megs of memory (on my machine), most of which is actually shared libraries, 
and not overhead for bash (libc, ncurses, libreadline, libhistory, etc), and 
no cpu time for that seven seconds (or more).  This is so little cpu usage 
that even on the oldest machines I've run runit on it doesn't even register 
as a single ms of cpu usage, if your desktop/server is worse...then stick 
with init, I guess...

Yes, for me, that is completely acceptable.  I don't agree that the overhead 
is necessarily any larger when restarting bash (cached exe image, fast 
startup times, and most of the "wasted memory" isn't actually wasted) 
compared to a need script running forever.  And frankly, I like the 
opportunity to do other things periodically when the script may fail a 
dependency check, such as taking it down if it has failed for too long, or 
clearing out a cache file that may have gotten in the way, an errant pid 
file, etc, etc, etc.  These are things that you cannot do with a need script.

Bottom line, the runit method is more flexible, and even if it uses more 
resources, it's fine by me (and it's still much less than traditional rc).

>
> > 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-ge
>neric/initscrcomconv.html [6]
> http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-ge
>neric/initsrcinstrm.html

I'm not actually going to pursue this.  My opinion, and I know I'm not alone, 
is that you should really let runit run the rc script and let the normal init 
scripts do the only thing they're mediocre at, or switch over completely to 
runit and drop the lsb/rc/sysv style.  Honestly, for someone who is 
self-professed "lazy" you're going through a lot of unnecessary work to hack 
a broken system into a nice one and lose all of the things except the cli 
that runit provides.  You won't actually gain nice script supervision this 
way, you won't be able to tell which services are really up or not except by 
testing the normal init status functions of the old init scripts, you will be 
able to "start" and "stop" the scripts, but it doesn't buy you anything 
useful.

Honestly, I was against sysvinit/rc style boot scripts for a number of 
reasons.  They're a pain to write and maintain, they offer no guarantees, 
there's an amazing library of bash scripts with every distro that *try* to 
sotra find programs that have been disowned completely, and there are no 
guarantees in that.

I wouldn't want a system that hacked init scripts into runit services to 
become popular, because it doesn't add anything, and it makes runit look bad.  
Runit is a wonderful new (in that not many people have seen the light yet) 
system that addresses many, many problems with other init systems and service 
systems.  I have seen several software packages that were absolutely 
brilliant die before their time because of improper use making them "look 
bad," and I don't want that to happen to runit.

If what you come up with really helps and is a definite improvement in doing 
things the runit way, then I applaud you, and if what you work on in the 
meantime works for you, then great, I'm very happy for you, but I'm not going 
to argue the point, I just hope that it doesn't wind up like so many 
marriages of technology and bringing out the worst in both parent systems.

--Mike

P.S.  I'm not trying to start a flame war or anything, I just really like 
runit, and don't want to see it fall into disuse due to misconceptions about 
how it works.  The beuty of it, the simplicty, and the assurances it provides 
are all thrown out the window by having the runit scritps start and disown 
processes of their own, then try to hunt them down later.  Please at least 
consider it.  I won't pontificate at you again ;)