[A rehash of an old subject. But rather than just comment about a
 specific implementation that I like based on "religious" issues, I
 want to cover the various options that are available, and what I see
 as pros and cons of each. I want to keep this discussion as objective
 as possible.]

There are a many different methods on maintaining the startup system
used by various UNIX derivatives. In short, they boil down to 
/etc/rc (BSD), /etc/rc.d/*, or /etc/rc?.d/* (SYSV), or a derivative of
these.

Now, whilst I believe that we shouldn't force SYSV semantics on
religious BSD zealots (flamebait - cause I'm a bit of the latter:),
I feel that the current system could be enhanced.

Here's a breakdown of solutions I see valid. I may not necessarily
agree with any particular pro or con, but I have heard people voice
them in the past:

-x-

1.	/etc/rc, /etc/rc.local, /etc/netstart, /etc/hostname.*,
	/etc/my{name,gate}, /etc/ifaliases, /etc/defaultdomain

This is the current implementation, inherited from 4.4BSD.

Pros:	- it's what's already there (don't change what works)
	- installation scripts can easily create a configuration
	  file for a specific network interface
	- no support for runlevels other than single and multiuser
	  (yes a pro and a con :)

Cons:	- too many files, too many places to look when changing stuff
	- need to edit the top of an executable script to control
	  features in other scripts (/etc/netstart)
	- not enough control over what starts in /etc/rc
	- no way of cleaning shutting down applications at shutdown
	  time (e.g, ORACLE, in-house databases)
	- no support for runlevels other than single and multiuser
	  (yes a pro and a con :)


2.	/etc/rc.conf, /etc/rc, /etc/rc.local

This is similar to what ULTRIX and OSF/1 uses. In short, /etc/rc.conf
contains a list of variables to be 'sourced' (via the sh '.' operator)
into the current environment, which then control the configuration of
the machine. All network interface and daemon startups are controlled
via an appropriate entry.

Pros:	- only one point of configuration
	- still follows BSD concept of /etc/rc
	- no support for runlevels other than single and multiuser
	  (yes a pro and a con :)

Cons:	- apparantly will make it more difficult for install scripts.
	  OSF/1, however, has 'update_rc_conf' as a front-end to this,
	  so I don't see this as that much of a problem.
	- no way of cleaning shutting down applications at shutdown
	  time (e.g, ORACLE, in-house databases)
	- no support for runlevels other than single and multiuser
	  (yes a pro and a con :)


3.	/etc/rc.d/*

A hybrid system of the original BSD /etc/rc, and the common SYSV
/etc/rc?.d/* scripts. The directory /etc/rc.d contains a list of
scripts, for each application or subsystem that needs to be
individually controlled. The scripts should support a 'start' and
'stop' argument, the former for startup, the latter for shutdown.
Links to these scripts which contain a numeric prefix can order the
sequence for startup (e.g, SxxScript) or shutdown (e.g., KxxScript).
A usable implementation of this for many platforms can be done with
Simon Gerraty's <sjg@quick.com.au> /etc/rc.sh script.

Pros:	- provides method of shutting down applications and databases
	  in a user defined order
	- easier to understand than a fully blown /etc/rc?.d/*
	  implementation
	- no support for runlevels other than single and multiuser
	  (yes a pro and a con :)

Cons:	- often unclear on the order items are started
	- often badly implemented
	- no support for runlevels other than single and multiuser
	  (yes a pro and a con :)


4.	/etc/inittab, /etc/rc?.d/*

The SYSV way of doing things. Very configurable (so I'm told), with
different run levels to provide incremental levels of service. Each
directory (/etc/rc0.d, /etc/rc1.d, {etc}) maps to the scripts to run
for that run level. The scripts have links as for /etc/rc.d/*.
Run-levels can make it easier to have the system available with full
services, but unavailable to users (i.e, maintenance mode).

Pros:	- different run levels

Cons:	- different vendors have different meanings for run levels
	- too complex for most situations

-x-


With that said, my personal preference is to immediately move to
/etc/rc.conf. It's easy, everything is in one place, and there's
minimal change.

In the medium term, I believe that a /etc/rc.d/* implementation should
be investigated, or the ability to provide an /etc/rc.shutdown system.
In systems where databases *must* be shutdown in a specific order to
prevent corruption, and you can't rely upon someone not forgetting to
Do The Right Thing, this can really save you.


Comments? Is there any chance that even /etc/rc.conf will be accepted
by NetBSD-core?


Luke

--
Luke Mewburn                            UNIX Technical Support
<lukem@telstra.com.au>                CPR Project, ITG, Telstra.
Phone: +61 3 9634 2112