Wow I saw a followup to this message 3 days ago, yet this only just
arrived.  

> HOWEVER (as i don my flak jacket), the SysV notions of:
> 
> 	(1) invoking something both when you're going up to and 'coming
> 	    down from' a given run level, and,

Very important for horrible things like databases.  Anyone who has
ever had to admin a system supporting these beasts will appreciate
this.  On SunOS machines, the best I've come up with so far is a
shutdown script that processes /etc/shutdown.d/* before invoking the
real shutdown.  Works well enough.

> 	(2) having multiple files to implement the 'rc' script, and
> 	    then looking through all of the ones present and running
> 	    them

> are _good_ ideas for a couple of reasons.

Well after reading this thread for a few days, I think there are quite
a few people who feel the same way.

I've never had a particular problem with inittab and run levels and
I've seen them put to some interesting uses.  As Chris says, I'm sure
its not the best way to tackle the problem, but it does work and is
very flexible.  I'm usualy in favour of a flexible implementation with
simple defaults.  If you like simplicity - just leave the defaults
alone :-)  

As for script dirs (I view this a being applicable to more than just
rc scripts) I agree with Chris.

> the second is nice a couple of reasons:
> 	(a) it's nice for users and/or third-party programs to be able
> 	    to insert things into the boot sequence, without worrying
> 	    having to hack the currently existing RC scripts.

Indeed.  Someone complained about problems with checking the order of
execution, but I've always found ls(1) did a good job.

> 	(b) it makes multi-machine maintenance a bit simpler; there's
> 	    little worry about the 'standard' scripts being modified
> 	    so, they can be upgraded easily, even rdisted.
> 	    additionally, one could easily add and subtract things on
> 	    a machine-by-machine basis.

I find this goes double for /etc/{daily,weekly,...}.d

> somebody has actually worked on this; they can pipe up about it if

I already did.

> they'd like.  I've not looked too hard at their implementation,
> though, because i've been too busy, because i figured a lot of people
> would object strongly, and because there is some 'groundwork' to be
> set up first...

Well, you could introduce the idea pretty simply, by just adding

/etc/rc.local.sh	(assuming /etc/rc.local.sh -> /etc/rc.sh)

or the explicit

/etc/rc.sh /etc/rc.local.d:S:start

at the end of /etc/rc.local.  If folk don't have the directory rc.sh
will do nothing, and if they do have local additions, its a much
simpler way to interface them - allowing the standard rc scripts to
remain as is until init et al are really ready.

I'm using the above idea on enough BSD and SunOS machines without any
pain to suggest that it is worthwhile.  On zen (i386) and hobbit
(sparc) I'm using rc.d, rc.local.d as well as shutdown.d without pain.

--sjg