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