Subject: Re: Proposed rc.d/rc.conf[.d] changes....
To: None <eeh@turbolinux.com>
From: Darren Reed <darrenr@reed.wattle.id.au>
List: tech-userlevel
Date: 05/08/2000 21:29:26
[...]
> > An RC script will typically do ". /etc/rc.config", which will source all
> > of the files in /etc/rc.config.d, at the top rather than read in just its
> > own config file explicitly.  From a system admin POV, it's a damn sight
> > easier to manage than the mess Solaris dumps you with.  You can even
> > start using RCS/CVS/SCCS in /etc/rc.config.d and *NOT* have to change
> > anything in order to prevent lossage.  There is *rarely* a need to edit
> > the RC files directly.

> I don't want to see yet another directory of scripts that need to be kept
> in sync with the stuff in /etc/rc.d.  In addition to the maintenance issue
> is the overhead of .sourcing each one of these little scripts.

Those "scripts" usually just contain things like:

NFSERVER=0
INTERFACE[0]="lan0"
etc

I'm also wary of storing parameter variables in more than one place -
it makes tracking things harder as well as "maintainance".

[...]
> > My main concern with NetBSD's rc implementation is the problem of
> > controlling what gets started at bootup and what gets stopped when
> > you shutdown. Having two separate directories (/etc/rc.d and
> > /etc/init.d) without adding S/K only alleviates one side of the problem.
> > I'm beginning to think that it may even need to be rototilled as the
> > shutdown side of things didn't seem to be very well thought through
> > during design/implementation by any of us.
> 
> I like the idea of adding an /etc/init.d to hold the primary copies of the
> rc scripts and copying/symlinking/hardlinking them to an entry in
> /etc/rc.d to enable them.  It's clean and you can immediately tell what's
> enabled and what's disabled.  
> 
> I don't want to se the S/K stuff which is ugly and a maintenance
> nightmare, and I see no need for that or an /etc/shutdown.d since that
> should be handled by PROVIDE/REQUIRE.  If it was started on the way up, it
> should be turned off on the way down.

If that worked, then Luke's 1st suggestion from his original email (the
need for a "shutdown" as well as "stop") would not be needed.

Apparently we have a problem with either the reverse order not working
or scripts that people don't want to run at shutdown that are needed
at bootup.

Darren