I know I'm late to this party, so appologies to all who are sick of
this thread, have already made up their minds etc.

I think most things that need to be said have been - but for the
record...

I think Luke's proposed start/stop script support (can't actually find
the proposal btw - only the followups) has a lot of benefits.  Though
I'd like to see only _one_ way to boot the system - anything else will
drive everyone crazy. 

I agree with everyone who says the svrV S300foo stuff is ugly, and
certainly not perfect - especially as Giles Lean pointed out, the
semantics surrouding the K* scripts - suck.  But it is a _simple_
and for the most part _adequate_ solution to the problem.  It has the
distinct advantage that adding a new service is just a case of
dropping a file (or link) into a directory.

I agree that the current /etc/rc /etc/rc.local stuff is bogus.
Sure it makes it easy for a human to read and edit and all that good
stuff.  Good for the person managing one or two servers.  But it sucks
ass when you want to manage 100's of servers all with slightly
different needs.  I don't know about anyone else, but if I can
automate a job I do it.

As Giles alluded to earlier, the solution I adopted long ago (which
gets used on lots of different *nix including NetBSD) was to leave
/etc/rc, /etc/rc.local alone and simply introduce an /etc/rc_local.d
which gets sysV style start/stop scripts - makes it trivial to
add/delete jobs and even re-ordering is not hard.  The important point
being that it all lends itself to automation.  A single 3 line
addition to the end of rc.local to cause rc_local.d to be processed.

Also for those that care, my rc.sh gives you the choice of running
things in sub-processes - handy to avoid env polution or within the
same process - handy for env frobbing.  Its sufficiently useful that
my /etc/{daily,weekly,...} jobs are all just links to rc.sh

I agree it would be nice to have a "correct" solution that does
sensible automated ordering of boot time tasks, but I'm not convinced
its a good idea.  I'm not convinced that the problem (task ordering)
warrants the complexity.

I agree that it is worth having something like rc.subr to provide
standard functions for getting pid's, killing them etc.  I do the same
myself /etc/rc_d/funcs.sh and use them heavily - and not just for
start/stop scripts.

But I think "for i in `rcorder /etc/init.d/*`; do $i start; done"
is a bad idea.  It means you need to remove a script from init.d to
stop it being processed.  Or you need to _also_ edit rc.conf in which
case you've immediately tossed some of the advantage of start/stop
scripts.

Either make links from init.d to say rc.d and use rcorder on that or
save the output from rcorder /etc/init.d/* in a file which is then
used - and can be edited to take services out.  Either way, running
the start/stop script should imply service=YES in rc.conf and that
file should only be used for supplying additional args - or not used
at all.

--sjg