Re: using runit as init

[Mike Buland <mike@geekgene.com>]

In general, if you want to retain init-style runlevels, then you don't want to 
replace SysV init.  I have switched to runit entirely, it manages every 
service, and it does indeed support "runlevels."  See 
http://smarden.org/runit/runsvchdir.8.html for details.  Each runit runlevel 
is really just another service directory, runsvchdir changes which service 
directory you are using.  the runit "init" program is provided mainly for 
compatibility.

There is no reason for runlevels to be numbered, and the kernel offers no 
support for runlevels, nor do any bootloaders.  When you pass 2, 3, 4, S, 
etc. to the kernel, it is ignored as an unrecognized parameter, but made 
available to running processes a number of ways.  Runit makes the commandline 
as well as any variables that are set on the kernel commandline available to 
the script 1 (and maybe 2 and 3, but I use it in 1).  Therefore if you set a 
variable in the bootloader on the kernel commandline named "runlevel" then 
you can use that in script 1 to change your runlevel.

However, I would say based on the way you are using runit as process 1, you 
would probably be better off sticking with sysvinit and adding runsvdir to 
your inittab (a script very similar to the example script 2 provided with 
runit is just what you want).

As for the runlevel code, I got this from this very list a long time ago, give 
it a shot in script 1:

# Set runlevel to:
# - single       if kernel has param: S
# - RUNLEVELNAME if kernel has param: runlevel=RUNLEVELNAME
# - default      if kernel has no params or unable to set requested runlevel
grep -q '\(^\| \)S\( \|$\)' /proc/cmdline && runlevel='single'
runsvchdir ${runlevel:-default} || runsvchdir default

This wored great for me, then in grub I added "runlevel=X" 
or "runlevel=console"

And finally, you want the normal setup, but point /var/service 
to /etc/runit/runsvdir/current, if it's not there, it will be created when 
runsvchdir is called, or you can create it yourself, it's a symlink to the 
current service directory.  Each directory in  /etc/runit/runsvdir is a 
complete (and normal) service directory.

utmp/wtmp support is done, I believe, through an external program, check out 
the getty*/finish scripts that are provided with the default distribution.

--Mike

On Thursday 03 January 2008 01:51:21 pm Bernhard Graf wrote:
> Hi list, happy new year!
>
> I'm playing a little with runit as replacement for SysV init as roughly
> described in http://smarden.org/runit/replaceinit.html .
>
> I adjusted the three runit stage scripts to play with an OpenSUSE 10.3
> Linux system. So far runit only supervises the (min)gettys, whereas all
> services that come with the distribution are still managed
> from /etc/init/rc that gets executed at the end of /etc/runit/1 .
> The whole thing is wrapped into two RPMs (runit and
> runit-sysvinit-compat) that replace the sysvinit RPM installation.
>
> Seems to work quite well, provided that I didn't do much more testing
> than boot, reboot, halt for now.
>
> What worries me now is a smooth transition for running systems from init
> to runit.
>
> In general I'd prefer to leave most service where they are, and just
> supervise certain ones, e.g. ssh, web server, all the djb s/w and
> custom daemons like FastCGI processes.
>
> The problem is that runit makes (nearly) no effort to support a system
> with supervised and "traditional" non-supervised daemons.
> Perhaps this is also the reason why runit didn't gain much attention in
> all the years, because concept and code are very well done AFAICT.
>
> At the moment I'm struggling with these questions:
>
> - A way to boot into a certain runlevel (say "init xxx" at boot prompt).
>   runit and runit-init don't care about these, where as (Smoorenburg's)
>   init passes the current runlevel in environment variable RUNLEVEL.
> - Changing runlevels. There is no way to say "init 3" anymore.
>   runsvchdir doesn't care about the SysV init scripts that are started
>   in /etc/runit/1.
>   runit-init only supports SysV init args "0" and "6" when not runing as
>   process 1.
> - utmp/wtmp support is missing completely, besides utmpset which should
>   be named utmpclr or so.
>
> Maybe somebody can give some advice or can share some example code or
> ideas.
>
> In case of interest and if someone has some public space at hand I would
> upload the SRPMs.