>What do people think about an /etc/init.d/ file, either with or
>without run levels?

runlevels? Just Say No. 

>                      I think run levels are mostly useless, but others
>will certainly disagree.  I would consider writing an /etc/init.d
>startup method if there was interest.  I really think the
>/etc/rc.local method is just plain archaic, and each package SHOULD
>have its own startup/shutdown script.

My $2.00 worth (which comes from exposure to Linux, with a raft of
startup/shutdown scripts, like /etc/rc.d/rc.{0,2,6,S,M,K,,inet1,
inet2,pcmcia,local}:

I, personally, fail utterly to see how /etc/init.d versus rc.local
affects start*up* scripts in any way.  Regardless of which scheme one
chooses, there are dependencies between [sic] modules, or subsystems.
One has to perform boot-time initialization of each subsystem.
Subsystesm, in general, have dependencies between them; and depending
on how large you view a subsystem, within a subsystem. (networking
daemons are a good example here: amd needs a SunRPC portmapper,
and possibly a YP map; and amd or a ypbind may need an interface and
routes, to contact NFS and YP servers.)

Partitioning all subsystems into two, or three, distinct steps (as
runlevels do) is not, and never will be, sufficient for all
interdependencies. I think CS theory is useful here.  The dependencies
between modules are a directed, hopefully acyclic, graph. (With down
and fully up, it's even a lattice.)   Runlevels are totally ordered.
Therefore they're not a strong enough mechanism for representing
*all* the dependencies between modules; and so (IMHO) they're not
the right tool to manage those dependencies.


That aside, I don't see anything stopping anyone from having an
rc.local that runs an independent startup script for each `package'.
(See /etc/netstart for one such script.)  I also don't see anything
from stopping us from writing scripts that take an argument to "start
up" or "shut down" a particular subsystem, or module.  BIND's ndc
script is a nice example here.

I think adding a mechanism to run shutdown scripts at a sensible point
during shutdown, before init kills user-level processes, sounds like a
good idea.  That should also address one well-made point that came up
in the last iteration: namely, starting up and shutting down database
systems.

To emphasise the point: yes, by all means, clean up and modularize the
startup process. And add a clean mechanism for running a script when
going from multi-user to single-user.  But runlevels?
I thought we buried that one last time!