Subject: Re: Allowing ${name}_path to be set in "rc.conf", was Re: Keeping /etc/defaults and /etc/rc.d in-sync
To: Andrew Brown <>
From: Robert Elz <kre@munnari.OZ.AU>
List: tech-userlevel
Date: 12/31/2001 18:28:31
    Date:        Sun, 30 Dec 2001 23:49:58 -0500
    From:        Andrew Brown <>
    Message-ID:  <>

  | no, you can't, since the connection from (for example)
  | /etc/rc2.d/S47thing to /etc/init.d/thing is either one of a symbolic

If the only requirement for editing was to alter the order the scripts
are run (including whether they are run at all) - which seems to be the
only real requirement now (everything else can be controlled other ways,
even if that means simply creating yourself a new script file), then
that scheme works.

I knew that when I sent the message - I didn't mention it because I was
looking for something better than what we have now, not something worse.

I didn't want to suggest this (hoping someone else would - so no-one would
tell me that if I want it, I need to write the code, as I don't have time
at the minute...) but the obvious way is to add a couple of args to rcorder
which could be passed in from rc.conf.

On the assumption that 99% of the time, what rcorder does will be adequate,
all that's needed is some way to tell rcorder to adjust its output to handle
the odd changes that someone might want to make.

I think 3 options added to rcorder would satisfy the requirement.

First (the easy one) "-i name"  (include the script "name").  This would be
relevant only when rcorder is run with -k (or -s) of course, and would cause
the script to be included, even if it doesn't (or does) have the keyword.
So, adding "-i swap1" to the shutdown rcorder args would be all that's needed
to cause swap1 to be run at system shutdown time (whether or not it ever
gets the KEYWORD: shutdown line added to it).

Second (almost as easy) "-o name" which would cause the named script to be
omitted - most of the time there's no need for this, it is easier to turn
off the process in rc.conf by xxx=no - but there are a few scripts (network,
etc) which aren't controlled that way.   This would also allow installation
of multiple scripts controlled by the same cmd name (so instead of having
to have:
	named=NO                named_flags="" 
type things (which I have on some systems), just "named=YES" would do, and
"-o named" would cause the named script to be skipped, with the "named9"
script having "rc_var=named" in it - that makes it much easier for people
who want to turn named on/off to not worry that there might be several
different named turn on vars in rc.conf, at most one of which is allowed to
be on.

And third (the hardest of these) "-d name1:name2" - which would cause rcorder
to make a dependency between name1 and name2 - or, if you like, to invent a
new notional keyword, have the name1 script "PROVIDE" it, and the name2 script
"REQUIRE" it - that is, in effect, force the name1 script to be run before
the name2 script.  In the event that -d args cause loops (or more likely, in
the event that loops occur and -d args were given) the correct response would
be to bitch & moan - and then forget the -d args (all of them) and try again.

Of course, using one syntax or another, each of those args needs to be able to
be set multiple times.


ps: while the Snn thing solves the obvious problem - you can update init.d
automatically, it doesn't actually achieve a lot - as new scripts added to
init.d don't ever get run unless something adds them to rcN.d for some
random N (in the SysV world).   So, to be useful, the rcN.d directories (or
just rc.d in NetBSD) would need to be automatically updated as well, which
then is either real easy, and the same problem occurs, or starts getting
quite complex, if you want to deal with people who have altered the standard