------- Blind-Carbon-Copy

From: Luke Mewburn <lukem@cs.rmit.edu.au>
Reply-to: lukem@cs.rmit.edu.au
To: tech-userlevel@netbsd.org
Subject: Proposed rc.d changes....
Date: Mon, 01 May 2000 23:36:52 +1000
Sender: lukem@goanna.cs.rmit.edu.au

[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...

------- End of Blind-Carbon-Copy