Subject: Re: /etc/default
To: None <email@example.com>
From: Leo Weppelman <firstname.lastname@example.org>
Date: 07/26/1995 17:28:00
> 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
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...