I've gotten mail from some folks who aren't familiar with the SVR4
run levels, and asked me to summarize what I'm working on doing.

The concept of run levels is this: that a machine can have a
number of modes that are clearly definable.   There's the
bare-minimum (ie, "standalone"), there's behaving as a client,
there's behaving as a server, and there's up for full login.

With each of these levels, there are a well defined set of daemons
that you want to be running: for example, in server-mode you want
to be running Kerberos, nfsd, etc.

The idea is that instead of having one mammoth script run when you
go from single-user to multiple user, you have a set of scripts that
correspond to each run level.  For example, for run level 3, there
are scripts in /etc/rc.3 that start and stop each service.  Usually,
there's one script for service, so that starting an NFS server would
be something like running:

	/etc/rc.3/S10nfs.daemon start

And stopping it would be:

	/etc/rc.3/K10nfs.daemon stop

The "S" is for the script that starts the service and the "K" for
the script that stops it, but they're usually links to the same
script that checks the argument.

The number following the "S" or "K" is the relative priority of
the script in that directory: they get run in order, from S00
to S99 when entering a level and from K99 down to K00 when
exiting a level (as I am implementing it).

This allows you to have two granularities for services: you can start
and stop them individually, or you can have them automatically run
when you go from one run level to another.  If you're in run level
1 and want to go to run level 4, all the startup scripts,
/etc/rc.2/S*,  /etc/rc.3/S*,  /etc/rc.4/S* are run with the argument
"start", while going from 4 to 1 would run /etc/rc.4/K*, /etc/rc.3/K*,
and /etc/rc.2/K* with the argument "stop".

What does this get you?  A number of things:

	- First, no single rc.local script.  This means that automatic
	installation of software (or your own modifications) can be done
	merely by dropping two scripts into the directory for the
	appropriate run level.  No ugly grepping of /etc/rc.local to	
	see whether it's already been installed, and no confusion
	about what the damned installation process just did: 

	- You don't add scripts to the standalone levels, so if you screw
	something up, you can just come up to the level below what you've
	entered, remove it, and then finish bring it up.  You can do this
	in a cruder way with standalone as is, but it makes you take
	an "all or nothing" approach.

	- If you want to bring a machine up as a client but not a server
	(useful in working on some network problems), all you need to
	do is specify the appropriate run-level.  Otherwise, you'd
	either boot a machine standalone and start everything but the
	server functions by hand, or you'll boot to multiuser and kill
	each deamon by hand.  Not fun.

What I'm doing to implement it is this:

First, I'm breaking up the /etc/rc, /etc/rc.local, and /etc/netstart scripts
into their component pieces, and putting them in directories corresponding
to the run-level I think is appropriate.  This is, of course, open to
debate: I just want to get the mechanism working.

Then, I'm putting scripts in /sbin that run each level as appropriate, and
putting a script in /etc/rc that just calls each of those scripts.

That's what I'll release immediately: no large change in functionality,
though you will be able to manually go from one run level to another
by calling /sbin/rc(whatever).  So far, so simple.

The next step is to change how inittab works, specifically adding the
idea of a run-level to anything started from the run-level.  This'll
require changing init to have the concept of the run-level, which should
add about couple hundred bytes of code & storage.

And that should be it!

Comments from folks?   I fail to see what the objection is.
--
L. Todd Masco  | "Hide, witch, hide!  The good folk come to burn thee, their
cactus@bb.com  |  keen enjoyment hid behind a gothic mask of duty." -JS/BATE