> cgd writes:
> >It's not clear to me that having the full SysV inittab generality is
> >really worthwhile...  
> 
> The idea behind is is good.  The way it is implemented on SysV is bad
> (and doesn't work at all as advertised in some implementations anyway).
> 
> The usual SysV inittab starts a lot of things separately that would be
> best started from a single script.
I think you should make the difference between the init(1M) and the
scripts surrounding it. I generally like the functionality of init.
The way the rc?.d directories are organized is questionable. The current
SVR4 implementation first executes the kill-files and thereafter the
start-files on a specific level. What I think is clearer is (I actually
implemented this): execute the start-scripts on entry and the kill
files on exit. This gives you a better overview of what exactly happens
on a specific level. There should be a pair of start/stop scripts in each
rc?.d directory.
The general init.d-directory makes it easy to stop just one application.
It just seems better to type 'init 2' or '/etc/init.d/xdm stop' than
asking for a ps-listing and killing xdm ;-)

> 
> It also lacks any standards on what functionality is provided at each
> run-level.  What you really want is to introduce names for specific
There is some standarisation. But it's generally dangerous to type
'init <number>' on a system you don't know, as someone might not have
specified a console entry on that specific level ;-) Fairly  standarized
are usually s,1,5,6. The actions on level 2 & 3 vary a bit. I think
this is just inherent to the possibilies. It's easier to standarize a
system with 2 runlevels compared to one having 9. This should never
be an argument to condemn flexibility.

> services and then have the subsystems specify what services the
> require and automatically start them in the right order.  E.g. if your
> database needs network services to be present it should say so.  If
> your turn-key system needs the database to be up and running it should
> say so.  You then run lorder  on the initialization scripts (so to
> speak) and execute them in the computed order.
I have my doubts if this is feasible. Exept when when you adhere to a
very strict standard of what should be done in a specific level. It should
be changable for a different ordering of levels.
> 
> What I really like about it is the ability to bring subsystems down in
> an orderly fashion when shutting down the system.
For some systems, it's really usefull to have a level multi-user with
only a console login and a multi-user level with all login possibilities,
as not all maintenance has to be done single-user...

Leo.