Subject: Re: Proposed rc.d changes....
To: None <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 05/01/2000 16:38:17
[ On Monday, May 1, 2000 at 10:11:32 (-0700), Eduardo Horvath wrote: ]
> Subject: Re: Proposed rc.d changes....
> I still think that the ON/OFF part should be handled by the script's
> presence or absence in the rc.d directory. Put the scripts in an init.d
> directory and copy them into rc.d to enable them. That should get rid of
> at least half of rc.conf, since most of that is turning services on and
There are advantages and disadvantages to both schemes.
First I'll reiterate that I prefer the "scripts in /etc/init.d with
(hard) links to /etc/rc.d to trigger execution" method. It's certainly
faster and a *lot* simpler. It's also more likely to be understood "on
sight" by the majority of generic "unix" system administrators.
However the primary reason I like having a *single* "rc.conf" file is
that it's one hell of a lot easier to do at least minimal change control
(eg. with existing tools such as RCS) than it is to do with any other
method (yes I could write a script that re-creates *all* of the links in
/etc/rc.d and then track changes in that script, but why should I have
to do that -- why not supply such a tool with the system?).
BTW, note that if you have a /etc/init.d and /etc/rc.d then you can also
have a /etc/shutdown.d and be done with the need for some special hack
in each script that shutdown can use to avoid doing anything special on
a system shutdown vs. when the admin purposefully runs the script with a
"stop" argument. Furthermore this gives the admin control over which
scripts actually do something on shutdown without forcing them to edit
the actual script.
Greg A. Woods
+1 416 218-0098 VE3TCP <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>