Subject: Re: run levels (was Re: The new rc.d stuff...)
To: None <current-users@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: current-users
Date: 04/24/2000 01:35:14
[ On , April 24, 2000 at 00:54:22 (-0400), Perry E. Metzger wrote: ]
> Subject: run levels (was Re: The new rc.d stuff...)
>
>
> I've never seen run levels used for any good purpose in any System V
> installation, and I've worked on some pretty huge installations. Never
> having seen a function for a facility leads me to belive that facility
> is not useful. Run levels have always been a solution looking for a
> problem, and they add complexity without giving any benefit in
> return. They were a bad idea, and I see no reason to further a bad
> idea.
Just because you haven't personally seen it or haven't had the
imagination to devise a use for it doesn't mean it doesn't exist.
Some production systems, particularly larger and truly general-purpose
central servers, have several operating states. They may change states
several times per day, or only once per week or whatever. Never the
less these "operating states" translate into "run levels" almost
directly with out much trouble at all. Any other solution would have
required inventing a similar state machine to run along side 'init'
anyway. Since 'init' is already a basic state machine it only makes
sense to enhance it the small amount necessary such that it can have at
least one more user-definable state. The concept of /etc/inittab also
makes for a much more reliable (i.e. single point of failure) design for
running daemons (i.e. instead of having each fork off into the
background on its own and then disappear for good if it should die).
The combination of moving daemon managment and additional operating
states into 'init' is quite logical and elegant.
Yes, user-named states would have been "nicer" but they're just fluff on
top of the basic concept of having a state table to manage the
transition of the system from one operating state to another.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>