This is alpha software, so be gentle with it!

This package contains scripts to provide three basic functions:

-- Create and maintain a start/stop dependency tree of services
   (rlc: -add, -check, -cons, -list, -parlist, -parshow, -show -sub) 

-- Based on this dependency tree, it sets up a start/stop schedule
   for the services (rlc-doit).

-- During a runlevel change, if it is fed a list of the currently
   running programs, it creates two files: one contains an
   appropriately sorted list of services to stop; the other one
   contains the sorted list of new services to start (rlc-go).
   "Appropriate" sorting means a sorting based on the schedule set up
   in the previous function.

What am I talking about?  Let us just concentrate on starting up
services. When a system is booted or enters a new runlevel, new
services are started.  Some of the services can start only if another
service is already running.  For example, ypserv has to be started
before ypbind.  In other words, some services depend on others. We
will call this `run dependency'.

Using the standard sysV sequence numbers, the sysadm can tell init to
start one service before another.  For example, in the startup
directory for runlevel 3, you might have the files

S40ypserv
S41ypbind

There are several problems with this approach, the main one is that
just by reading the sequence numbers, one cannot tell the exact
dependence of the services. Indeed, you might have

S40ypserv
S41ypbind
S50qmail

though `qmail' possibly does not rely on `ypserv' or `ypbind' (our
sysadm did make it rely on them!).  So if you are not very
knowledgeable, you may not dare to remove `ypserv' from your system for
fear that `qmail' may not be able to run properly.

Another problem (related to the first one) is to try to squeeze a new
service into the startup schedule.  If you had to do this frequently,
you know how much pain it could be to decide on a good startup number.
A possible scenario is that you might receive a package that comes
with an initscript with preassigned startup numbers, but with no
specific hints on what the new service really depend on for startup.
Then you need to go after this extra info.

Now, with the runlevelconf package, you add a new service to the
startup list for runlevel 3 with a  command like

rlc-add 3s linuxconf syslog inet

to say that you want to add `linuxconf', and it should be started up
after `network' and `inet'.

To see the dependency tree for the startup of services for runlevel 3,
you type

rlc-show 3s

and you might see something like (the actual dependencies are
different; this is just an illustration)

3s
|-- network
|   |-- qsmtpd
|   `-- ypserv
|       `-- ypbind
`-- syslog
    |-- qmail
    `-- ypserv
        `-- ypbind

This says that `network' and `syslog' does not depend on anything for
startup, `qmail' depends on `syslog' only, and `ypbind' depends on
`network', `syslog', and `ypserv'.  Just to make sure, you can type

rlc-parlist 3s ypbind

to get

Parents of ypbind:
network
syslog
ypserv

The tree above also indicates how services should be started:

first: syslog and network (it does not matter in which order since
they do not depend on each other)

second: qsmtpd, ypserv, qmail

third: ypbind

You tell runlevelconf to find this schedule by doing

rlc-doit 3s

This command sets up the directory 3s-schedule, and in it you find

# cat 3s-schedule/1
network
syslog

# cat 3s-schedule/2
qmail
qsmtpd
ypserv

# cat 3s-schedule/3
ypbind

Similarly, you can optionally create a 3k-schedule, a schedule for
stopping services at runlevel 3. if needed.

Just to use a different example: if the mail spool directory is NFS
mounted (it is a horrible idea with sendmail), you do not want to run
the script, say netfs, that unmounts remote file systems before until
the local mail delivery agent is stopped.  Otherwise, your mailer
might decide to permanently bounce messages during an NFS outage.

So you might have the following 3k tree:

3k
|-- netfs
|   |-- nfs
|   `-- sendmail
`-- slapd
    `-- slurpd

The meaning of this tree is the same as that of a start tree, since,
remember, these trees show run dependence.  So, for example, sendmail
depends on netfs while running.  So, in case these services are to be
stopped at the transition to runlevel 3, sendmail should be stopped
*before* netfs.  Indeed, rlc-doit recognizes that 3k is a stop tree,
and 

rlc-doit 3k

comes up with the following schedule:

# cat 3k-schedule/1
nfs
sendmail
slurpd

# cat 3k-schedule/2
netfs
slapd

Now what you do with these schedule files depends on how you start
services on your system.  To help you out, runlevelconf includes the
rlc-go script.  Here is how it works.

We assume that you have a `runlevel.init' script (very similar to the
usual `rc' scripts) that runs `rlc-go' in the following way.  Suppose
the system is about to change to runlevel 3.  The script
`runlevel.init' first creates the file 3.current containing a (not
necessarily sorted) list of all the currently running services, and
then runs

rlc-go 3

`rlc-go' examines the contents of 3.current, 3s-schedule/ and
3k-schedule/, and creates the files 3.start and 3.stop.  

The file 3.start contains an appropriately sorted list of services
which should be started at runlevel 3---but it excludes those services
that are in 3.current, since there is no need to start already running
services.  

Similarly, the file 3.stop contains an appropriately sorted list of
services from 3.current that should be stopped.  Now all
`runlevel.init' has to do is

-- stop the services in the order they appear in 3.stop.  This usually
   is accomplished by doing something similar to 

   for i in $(cat 3.stop); do
       /etc/rc.d/init.d/$i stop 
   done

 
-- start the services in the order they appear in 3.start. This usually
   is accomplished by doing something similar to 

   for i in $(cat 3.stop); do
       /etc/rc.d/init.d/$i start 
   done 


Here is an example of what `rlc-go' does.  Let us use our previous
trees, so you have 

3s
|-- network
|   |-- qsmtpd
|   `-- ypserv
|       `-- ypbind
`-- syslog
    |-- qmail
    `-- ypserv
        `-- ypbind

hence

# cat 3s-schedule/1
network
syslog

# cat 3s-schedule/2
qmail
qsmtpd
ypserv

# cat 3s-schedule/3
ypbind

and let us say, you also have

3k
|-- netfs
|   |-- nfs
|   `-- sendmail
`-- slapd
    `-- slurpd

hence 

# cat 3k-schedule/1
nfs
sendmail
slurpd

# cat 3k-schedule/2
netfs
slapd

Now assume 

# cat 3.current
qmail
netfs
slurpd
slapd
routed
gpm


Then 

rlc-go 3

produces the following:

# cat 3.stop 
slurpd
netfs
slapd
gpm
routed

Notice that `slurpd' is listed first since it is in 3k-schedule/1,
then `netfs' and `slapd' since they are in 3k-schedule/2.  Since `gpm'
and `routed' are not in 3k-schedule, they get stopped last.

Also note that `nfs' and `sendmail', while they are in 3k-schedule/1,
they did not make it into 3.stop, since they were not running (are not
in current).

# cat 3.start
network
syslog
qsmtpd
ypserv
ypbind

Notice that while `qmail' is in 3s-schedule/2, it did not make it into
3.start since it was already running.

Finally, you might ask "What happens if a service appears in both the
3s and 3k tree?".  

Well, first of all, you can avoid such situations by running the
consistency checker script, `rlc-cons'.  You may get an output similar
to

# rlc-cons 3               
Runlevel 3 is not consistent;
common services in 3s and 3k:
ypbind
ypserv

But to answer the question: if a service appears in both the
3s and 3k tree, then it will not appear in 3.stop, and either it will
appear in 3.start, or it was in 3.current.  This means that the
service will be running at the new runlevel, 3 in this case. 

The MANUAL file contains the description of all the rlc-* scripts;
presently, they are

 
rlc-add
rlc-check
rlc-cons
rlc-doit
rlc-go
rlc-help
rlc-list
rlc-parlist
rlc-parshow
rlc-remove
rlc-show
rlc-sub