Subject: Re: Proposed rc.d changes....
To: Luke Mewburn <email@example.com>
From: None <firstname.lastname@example.org>
Date: 05/01/2000 11:38:55
> 1. Using `shutdown' instead of `stop' as the argument to
> 2. Adding the ability to specify a user to run as, a nice
> level to run at, etc. (xref PR 9954)
> The first two are about to be committed, barring serious objections.
> The rest probably need some more discussion.
no problem with those.
> 3. Reworking the configuration mechanism (replacing rc.conf)
> If a tool is provided (e.g, virc(8)) which presents
> /etc/rc.conf.d/* as a single editor buffer, which then
> rewrites /etc/rc.conf.d [...]
Which I believe exists in some form already. See
http://gdev.net/~vpp/virc.tar.gz, written by Scott Bamford.
(I haven't tried this)
> From an implementation point of view, another rc.subr function
> - load_rc_conf() - would be used to load this config file.
> Others have suggested very configurable configuration
> mechanisms [excuse the wording ;], but I feel that such
> proposals would result in making a system that was *too*
> configurable and harder for us (as a project) to support
I was one of the people that suggested this. After thinking
a bit on the impact this would have on the speed of the rc.d scripts
I agree with Luke here. However, in an effort to keep some backwards
compatibility with a single rc.conf I think that the load_rc_conf()
function should unconditionally load rc.conf before the individual
I ran some speed tests on the different variations. This is on
an AMD K6-233:
(and a comparison between old and new /bin/sh just for fun)
Ways to read config files:
New sh Old sh
Time(s) Index Time Index
1) Individual files only: 0.11 1.0 0.81 1.0
2) With full rc.conf 0.80 7.3 2.50 3.1
3) Empty rc.conf 0.14 1.3 0.91 1.1
4) With test for rc.conf 0.19 1.7 1.50 1.9
The script I used looped over 200 config files created from
the /etc/rc.d files. All tests read these files in. Test
#2 also did a ". /etc/rc.conf". Test #3 instead read in an empty
file. Test #4 tested for the existance of the empty file
before reading it in. (slightly faster if it didn't exist)
The actual difference with the new /bin/sh (Test #1 vs #4) is
only .08 seconds. Even on a machine that is 100 times slower than
mine this is only 8 seconds slower. Since it helps everyone who
hasn't yet moved their config over to the split config scheme (==everyone)
I think this is an acceptable slowdown.
Also, how about having /etc/rc check for /etc/rc.conf
and spitting out a message if it exists, saying that it is deprecated
and will go away in the next release?
> users. Having rc.d configuration information potentially
> coming from three sources (the rc.d/foo script, rc.conf or
> rc.conf.d/foo), with different variations on which source
> takes priority, sets off `difficult to support' alarm bells.
Yes. But, it would be nice if there was a specified default for
configuration information. This isn't exactly configuration info but
a way to be able to reliably see what a particular rc.d script does
by default. (which would generally be "nothing", i.e. off) This would
also mean that you could have much cleaner configuration info that
only specified how a particular machine differed from the default.
The obvious place for this would be in the rc.d scripts, before
load_rc_conf() reads in any configuration.