[bcc-ed elsewhere to inform people of the existence of the discussion]
There's a few areas in which rc.d needs to be improved (*). I'm going
to attempt to cover some of those here. A summary of the issues
covered is:
1. Using `shutdown' instead of `stop' as the argument to
rc.d scripts at shutdown(8) time. (Simon Burge posted
about this last week)
2. Adding the ability to specify a user to run as, a nice
level to run at, etc. (xref PR 9954)
3. Reworking the configuration mechanism (replacing rc.conf)
4. Supporting pkgsrc rc.d scripts
5. Supporting third-party (non system) scripts
The first two are about to be committed, barring serious objections.
The rest probably need some more discussion.
Details:
1. Using `shutdown' instead of `stop' as the argument to rc.d scripts at
shutdown(8) time. (Simon Burge posted about this last week)
The rationale for this is that for a couple of reasons
(including speed and system stability in the case of potential
deadlock), having all of the rc.d scripts run with an argument
of `stop' at shutdown is not necessarily the best idea.
A suggestion has been to change /etc/rc.shutdown to call
the /etc/rc.d/ scripts with `shutdown' instead of `stop'.
That way, manual control of scripts is still possible, but
only those scripts which explicitly need to be shutdown
(e.g, xdm) are done so. Everything else will just rely upon
the SIGTERM from init(8).
2. Adding the ability to specify a user to run as, a nice level to run at,
etc. (xref PR 9954)
A PR was submitted recently which added support for changing
the user, priority, and working directory of a script.
I took a look at the PR, and implemented the functionality
based on the PR (albiet fixing a few bugs a long the way ;-)
3. Reworking the configuration mechanism (replacing rc.conf)
Be warned; this is a contentious issue!
After many discussions with a variety of people, it appears
that the configuration mechanism for rc.d should have the
following attributes:
* simple/stable
* easy to manage by a user
* easy to manage by system/automated scripts
* easy to upgrade
Whilst rc.conf is easy to manage by a user, it's not trivial
to safely update it mechanically, nor is it easy to upgrade.
My proposal is to replace rc.conf with separate
/etc/rc.conf.d/foo config files, one for each service, with
contents similar to:
foo=NO
foo_flags="-q ex0 -p 667"
The primary concern with such an approach (and it's one I've
had) is that it's not as easy for a user to manage multiple
services at once (or setup a system from scracth). 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 as
necessary once the editor is successfully exitted, then I
believe that this concern will be addressed.
From an implementation point of view, another rc.subr function
- load_rc_conf() - would be used to load this config file.
Thus, if someone *really* wants to retain rc.conf in their
setup it's trivial for them to edit /etc/rc.subr and modify
a single function to change how config files are sourced.
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
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.
We chose to support only one rc.d mechanism (as opposed to
rc.d, /etc/rc, and SYSV init.d) for similar reasons; stick with
one method, but make it easy for an individual site to
consciously modify scripts if other behaviour is required.
With load_rc_conf(), a site which wants to retain /etc/rc.conf
semantics could do something like:
- edit rc.subr to source rc.conf as well as the per
program configs
- append /etc/rc.conf.d/* >> rc.conf
- rm /etc/rc.conf.d/*
and then be responsible for maintaining their configuration
`in sync' with any future system or package tools.
4. Supporting pkgsrc rc.d scripts
I suggest that the pkgsrc system is setup such that we supply
and install rc.d scripts that are written to work as our
system scripts do, in that:
* our configuration mechanism is used
* the rc.subr helper functions are used
* appropriate PROVIDE/REQUIRE dependancy elements are set
Also, by default, the package should setup things such that
the program is started by default, since this is the principle
of least surprise (and effort :-) for the majority of our
users. Of course, I suggest that we add support to install
it disabled with something like an mk.conf variable such as
`PKGSRC_RC_D_DEFAULT_DISABLE' being set.
5. Supporting third-party (non system) scripts
Third-party scripts should `just work', as long as they
support keywords such as:
start, stop
and possibly
restart, reload, status, shutdown, [...]
(see above WRT `shutdown'), and if necessary, appropriate
PROVIDE/REQUIRE lines are added to the script, then the
script should `just work'.
There shouldn't be any need to use the rc.subr helper
functions (although there's no reason why they can't be used),
nor should there be a dependancy on using the config mechanism
specified above.
In order to be compatible with certain conventions used in the
system scripts, the script could support argument prefixes such
as `fast' and `force'. (Check the description of
run_rc_command() in rc.subr for more explanation).
Luke.
(*) Note to the peanut gallery; I'm sure a few vocal non-rc.d liking
users might take this as an opportunity to start rubbishing rc.d
again. Please don't bother; we've heard it all before, and I'll delete
any such messages without replying EVEN if there's a possibility of a
sane idea in the message. I.e, if you want to constructively contribute
to the discussion, please do. Otherwise please keep your `reply'
trigger finger idle for a while...