Subject: Re: rc.d (Was 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 13:04:27
[ On Monday, April 24, 2000 at 11:03:17 (-0400), Bill Sommerfeld wrote: ]
> Subject: Re: rc.d (Was Re: run levels (was Re: The new rc.d stuff...)) 
>
> IMHO, if you want to be able to dynamically enable/disable subsystems
> based on dependancies, you need to keep track of which ones are
> currently running.

You could make some assumptions (i.e. assume that the user will usually
ask for a state transition that'll make sense) and then do things in a
way that won't cause failures if things aren't found to be exactly the
way they should be.  This isn't perhaps as 

This could be implemented with "rcorder" by simply adding the ability to
specify a desired "target" (eg. "network") and "direction" such that it
would list only those scripts that would need to be run to stop or start
a given sub-system and all of those sub-systems it depends upon.

> I think this would be best done using a different model for starting
> daemons/subsystems, more akin to an inetd/init model (where a
> management daemon remains as a parent to the managed services) as
> opposed to an rc "fire and forget" model.

Exactly.  This is why SysV had run levels and used them to implement a
state machine!  ;-)

Especially in this day and age when getty processes on real terminal
ports are much less common and important it seems to me that 'init' is
the natural place to integrate a daemon and subsystem monitoring and
control feature.

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