You could also try the following:

http://fedorafastboot.wiki.sourceforge.net/The+Runlevel+Scheme

It is something I have been working on for a couple of months and is a little rough around the edges. Mainly developed for fedora but it is fairly generalised so I guess it can easily be ported. There are no 1, 2 and 3 scripts as described in the runit docs. Runit is controlled by inittab. Each runlevel change runs a runsvchdir command to a different directory. So for each service you are monitoring you will need a symlink for that service in the runlevel directories. You will need to put a 'runsvdir -P runlevel1' command somewhere early in the startup - I have it right after there is a r/w filesystem and selinux relabel or just as the last command in rc.sysinit.

so something like :

runsvchdir runlevel1
runsvdir -P /var/service

runlevelS can be symlinked to runlevel1 or have it's own directory.

 Init is still process 1 and init runlevels run as normal. No changes to the kernel parameters are neccessary (as it is still init). The checksrv.sh and checksrvgtk.sh (gui for x using zenity) scripts are quite useful in seeing what services are running/stopped or failing and they should work fine in Suse (there might be bashisms that need sorting to get them working ok). Annvix distro has a pretty good script for managing runit services (which works on fedora, but there are long delays (~2-3mins at least on fedora) while it figures out if a service is failing. The above scripts can get the status quicker although there is a small chance it might be inaccurate (1 in every 100 times it is run) for a failing service.

The init scripts are direct ports of the fedora scripts so they might only be helpful to you as additional examples of how to start a particular services.

I haven't done much work on the runlevel scheme as I mainly use the incremental scheme (which gets me to a desktop fast). If you try it I would appreciate any feedback on what works and more importantly what doesn't.

regs
Rehan

-----Original Message-----
From: Bernhard Graf [mailto:list-supervision@augensalat.de]
Sent: Sat 1/5/2008 00:15
To: supervision@list.skarnet.org
Subject: Re: using runit as init
 
Mike Buland wrote:

> 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 I wrote in my previous email I want an easy way to switch from SysV 
init to runit (or may be another one that supports process 
supervision). Since I have to care for a couple of production systems 
this switch must meet some conditions:
- full support for the old init system
- keep manual adjusting to a minimum

ATM I'm starting daemontools svscan from inttab on those hosts in 
addition to the normal SysV init stuff. This works but is not really 
pretty - I'd like to have a more consistent administration interface.

The goal is to install runit with RPM, reboot and then link the 
daemontools things into runit's service directory.

> 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

Good tip! /proc/cmdline seems a smart way. Question 1 resolved. :-)

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

utmpset only clears lines from utmp, there is no way of setting anything 
as the name suggest.

-- 
Bernhard Graf