[ On Monday, April 24, 2000 at 11:26:19 (-0700), Greywolf wrote: ]
> Subject: Re: rc.d (Was Re: run levels (was Re: The new rc.d stuff...)) 
>
> On Mon, 24 Apr 2000, Greg A. Woods wrote:
> 
> # Especially in this day and age when getty processes on real terminal
> # ports are much less common and important...
> 
> ...in your opinion.  I do most of my work on a command line.

Ah, please re-read what I wrote there.  I didn't say anything at all
about pseudo-ttys, xterms, command-lines, or anything similar.

I too do most everything except reading&writing e-mail, and writing
code, from the command-line too.

> # ...it seems to me that 'init' is
> # the natural place to integrate a daemon and subsystem monitoring and
> # control feature.
> 
> I think that's giving init entirely too much credit/responsibility for its
> ability.

Why do you think that?  It already takes most of the credit and assumes
most of the responsibility in many cases anyway so I think you're wrong.

Init is already responsible for running /etc/rc and thus ultimately
responsible for starting everthing in the first place anyway.

On systems with actual tty ports in use init is also responsible for
keeping a getty process running on every tty, restarting them when they
fail or exit.

In other words init is already responsible for all the core
functionality and access control of the system from the ground up.

Furthermore init is already treated as one of the programs that needs
the highest quality and reliability in the entire system, second only to
the kernel itself I'd say.

Since init already restarts processes that exit adding the ability to
manage long-running daemons to init doesn't really require any change at
all (you can fake it today in fact), and certainly doing so won't
increase the complexity of the program at all (and will only shake up
the reliability for the duration of the change).  All that's really
necessary is to clean up the syntax of /etc/ttys a bit and to rename the
file so that it doesn't mislead anyone (/etc/init.conf perhaps?).

Adding externally accessible state control to init doesn't really make
it much more complex either -- it's already a state machine on the
inside -- and doing so will make it possible for init to control part of
the shutdown process and thus make it possible to very elegantly fix
some of the problems with the current rc.d shutdown process that I and
others have complained about.

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