> > Chris G Demetriou writes:
> > > It's not clear to me that having the full SysV inittab generality is
> > > really worthwhile...  (i, personally, have always found the notion of
> > > having N different run levels annoying. 
> > 
> > Agreed. They do no good. On the other hand...
> 
> You fellows don't seem to have dealt with machines that need fine
> control over several different operating states.  It makes for very easy
> implementation of some specialized turn-key systems.

I tend to agree with the camp who is arguing in favor of simplicity. 
I agree that it is too hard to install packages, and I don't
like editing rc.local any more than the next person; hence I
always append something like:

	if [ -f /usr/local/etc/rc.reallylocal ]; then
		echo -n "Starting local demons..."
		. /usr/local/etc/rc.reallylocal
	fi

at the end of rc.local, and leave it at that.

My objection to all the SysV-ish mechanisms (and I use them -- I
am still the owner of a 3B2 used for email) is that they are
too complex.  They they depend too much on things like numeric 
sequence numbers; and there's not good way to make sure by
inspection that things are happening in the right order.
Certainly I find that to be true when examining other 
people's SysV startup scripts....  The same is true when
trying to determine the effects of run levels.

This is really a problem when one is trying to build things
like gateways.  I have much more confidence in my NetBSD firewall
than I would in a SysV-ish firewall, if only because I can
examine the startup command files and find out both not just
the list of operations, but also the sequence, by examining 
just a few files.  This is harder to do with SysV.

[To work by a strained analogy:  SysV's start up sequence reminds
me a bit of sendmail -- infinitely flexible, and therefore
tricky to ensure correctness.]

Let me make a really wild suggestion that is really impractical:
rather than copying SysV, someone should figure out how to
do the following:

	* define system states symbolically (not via
	  numbers)  (e.g. multi-user, etc.)

	* provide classes of dependencies for start-up
	  script ordering, both forward and backward.
	  
	  Each script would have lines (as comments,
	  perhaps) at the front:

		#!/bin/sh
		#precondition:   network, nfsmounts
		#postcondition:  MCCI/database, multiuser
		#
		# This script brings up the special
		# MCCI xyz database server.

	  One would want to have system conditions, and
	  local conditions, ideally prefixed by the 
	  organization in order to allow intermixing
	  of scripts from other people.  The tags
	  indicate (as preconditions) that we must first
	  run all the scripts that declare "network"
	  as postconditions; and also all of the scripts
	  that declare "nfsmounts" as postconditions.
	  We'll declare "MCCI/database" and "multiuser" as
	  a postcondition (on successful completion).

We'll define that we won't be in state multiuser until all 
the scripts that are marked as having postcondition
"multiuser" have been run; and we'll also assume that
a smart topological sort will be run that either 
creates a correct partial order or detects cycles and
complains.  

Dummy scripts could be used to collect all the
well-known preconditions:

	#!/bin/sh
	#precondition:	network, nfsmounts, swapon, daemons,
	#		{your favorites here}
	#postcondition:	multiuser
	#
	true	# this script is just a placeholder!

System states would be declared as lists of desired 
post-conditions; init or rc would invoke a program that
would create a graph of scripts to be run based on
the target post-conditions, and would guarantee 
that the preconditions were satisfied
for each script before that scripts is run.

To the extent that things can be shut down in reverse
order, the startup and shutdown scripts could be combined,
ala SysV; but this may not be a correct assumption!

If one were bloody-minded, one could get to the various
system states by simply forcing all transitions after
boot to go via single-user mode.  

One could even create the SysV-ish links in /etc/rc*.d
statically based on headers on files in /etc/init.d,
then use the dumb SysV approach - but that doesn't help
us with the arcaneness -- and arbitrariness -- of
the run levels.

--Terry
tmm@mcci.com