Leo Weppelman writes:
>I think you should make the difference between the init(1M) and the
>scripts surrounding it. I generally like the functionality of init.
Exactly.

>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.

That's one of the problems I had in mind when I said that it doesn't
work as advertised.

>What I think is clearer is (I actually
>implemented this): execute the start-scripts on entry and the kill
>files on exit.

This is what we did on the SVR3 port I was working on years ago.

>There is some standarisation. But it's generally dangerous to type
>'init <number>' on a system you don't know,

The big problem isn't with typing 'init <number>' but rather that
software installation skripts have no way to autmatically figure out
at what run-level the software should be started.  And the Snnxxxx
files in the rcN.d directories make it impossible to automatically
insert the start-up script.

What is really needed is a description of the prerequisites as in the
following paragraph.

>> 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.

I believe it is feasible.  The problem I see with SysV /etc/initab,
/etc/rcN.d/* and the run-levels is that the system tries to solve a
number of different problems with a single tool: flexible and
automatic installation of rc skripts for software systems, invocation
of these scripts in the right order and konfigurations management of
the system.  These really should be split and handled by different
tools.

>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...

We already have that: /etc/nologin.  Though that really is a hack.

-- 
Christoph Badura	bad@flatlin.ka.sub.org		+49 721 606137

Es genuegt nicht, keine Gedanken zu haben;
man muss auch unfaehig sein, sie auszudruecken.  - Karl Kraus