Re: using runit as init

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

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/
-- 
Bernhard Graf