Re: using runit as init

[Mike Buland <mike@geekgene.com>]

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

If this feels less elegent to you than "need X" you could always wrap it with 
another script. that would just make your scripts look prettier.  Also, this 
has a few interesting advantages.  Firstly, sv start X will wait be default 
for 7 seconds for the service to come up, even if it's already in the process 
of starting, so there are never any conflicts.  If the service is already up, 
it returns immediately indicating success.  If the service has not come up 
yet, or something has gone wrong, it will return non-zero and the hal script 
(in this example) will also exit non-zero, indicating an error and runit will 
retry a second or two later.

This is very similar to the need method, except that in my opinion it has a 
few advantages, especially relating to the asynchronous nature of the way 
runit works.  In the above example, there is no extra accounting being done, 
no extra programs need to be written, it is efficient, safe, and will keep 
trying in case there's a temporary error on either service.

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?

In the former case, I can't understand why you would want the rc script to be 
handled by a service, you're right, you're gaining very little, and making 
extra work.  The two ideologies are diametrically opposed, you can't really 
reconcile them, nor should you be able to.  However, using runit as init 
gives you three scripts that run that let you do anything you want.  When I 
was transitioning from SysV to Runit inits I simply called rc in script 1 and 
3 and left 2 more or less alone from the reference.

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.

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.

It's really the closest I can come to a cleaner hack, but really, I would go 
with the former option or just sack the SysV style and switch over entirely 
to runit, it's so much nicer and anyone can make the run scripts, most of 
which are only a couple lines...

--Mike

P.S.  If you really want to go with the "down" idea, and not have a dummy 
service running that you can stop later, and that runit can stop 
automatically for you at system shutdown, etc.  Then consider just adding a 
couple of lines such as:

touch /etc/rc-compat/down
sv start /etc/rc-compat

into your script 1, don't put it in 2, if 2 dies it's restarted, and rc 
scripts shouldn't be called more than once in a row if it's avoidable.  The 
above case will ensure there is a down file, and start the service, when the 
service finishes, it will not start.  Be aware that this is basically the 
uber-complex version of just calling the rc script by hand, and really gives 
you nothing except concurrent execution of the rc scripts and the other runit 
processes, which could also be accomplished in bash with a &.

On Wednesday 09 January 2008 04:06:54 pm Bernhard Graf wrote:
> Vincent Danen wrote:
> > Yeah, Annvix is a lot of work.  =)  And thank you.  Execline is
> > definitely nice..  using it with dietlibc for some stuff (like
> > mingetty and runit itself) really keeps the overhead down.
>
> I've had no luck with execline and dietlibc: Got "segmentation fault"
> errors that went away after building execline with glibc.
>
> Of course I should test this a bit further and file an error report...
>
> > >> That's got the relevant runit scripts we use to handle init.  Note
> > >> that we don't completely do away with sysvinit... there are some
> > >> useful tools that come with it; we just don't use sysvinit's init.
> > >
> > >Actually I'm missing two essential things in runit, that would allow
> > > to replace "standard" (Linux/SysV) init while keeping the
> > > start/Stop scripts in the beginning:
> > >
> > >- possibility to set no-respawn mode for a service, instead run
> > > command (e.g. "/etc/init.d/service start") when service appears in
> > > runsvdir's directory and run other command (e.g.
> > > "/etc/init.d/service stop) when it disappears
> >
> > Wasn't this addressed already?  Or maybe I'm missing something?
> > Can't you use the down script?  I.e. you could use run to start it
> > and once it exits, doesn't runit look for the down script to execute
> > prior to restarting?  If so, you could use a 'sv down' or something
> > similar (maybe even something as simple as touching 'down') to
> > prevent it from starting again, right?
> >
> > Of course, if you do something like that, you might need to write a
> > wrapper that would remove the down file before calling 'svc up'.
>
> I would like to just link init scripts into runsvdir's directory, so
> they are started automatically. But as we know init scripts terminate
> and runsv would restart them immediately. I'd like to have a
> non-respawn mode for runsv.
> I think this could be realised by a wrapper that is called by runsv,
> runs the SysV start script and then waits for SIGTERM.
>
> But maybe I'm missing something and there is already a way to achieve
> this.
>
> > >- service dependencies
> >
> > We've tackled this somewhat, but Annvix has a frontend called srv
> > which handles the dependencies.  It's quite crude and definitely
> > could use some work, but we've found there are very few things
> > outside of nfs that have strict "service X needs to be up and running
> > before service Y" dependencies.
>
> About service dependencies: There is a link on Gerrit's site to an IMHO
> elegant way: [3], realised in [4]. This concept would require changing
> how runsvdir starts services.
>
> Having all this it would be simple to convert the links in directories
> /etc/init.d/rc[0123456S].d into correspondig links
> in /etc/runit/runsvdir/[0123456S] and replace init-daemon-install-tools
> like chkconfig or insserv by runit-compliant versions.
> So no need to change all daemons with those init.d start-stop scripts.
> Even those that are installed later would continue to work.
>
> > >Another interesting project is ninit [1] and its ancestor minit [2]
> > >
> > >[1] http://riemann.fmi.uni-sofia.bg/ninit/
> > >[2] http://www.fefe.de/minit/
> >
> > Never looked at these.  svscan is definitely useful.  Do they
> > supervise services as well?
>
> Of course they do. Those don't respawn terminated processes by default,
> but can be told to do so. Supervising is done by [mn]init directly, so
> there are not n supervisor processes for n supervised processes, but
> only one process that usually runs at pid 1 and supervises all n
> processes.
>
> Another interesting feature: You don't have to put an executable program
> into run, instead run can be a softlink to a program and params for
> this program are simply stored in a file named params.
>
> Instead of starting a getty in a script:
> #!/bin/sh
> exec /usr/bin/setsid /sbin/mingetty --noclear tty1
>
> just symlink run to /usr/bin/setsid  and put into params:
> /sbin/mingetty
> --noclear
> tty1
>
> Thus no shell (or any other interpreter like execline) has to be loaded.
>
> [mn]init doesn't poll the service directory as svscan/runsvdir do.
> Can be seen as advantage, when you don't want permanent disk access.
>
>
> [3] http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/index.html
> [4] http://www.kernel.org/pub/linux/utils/util-linux/