On Mon, 8 May 100, Darren Reed wrote:

[...]
> /etc/rc.config.d
> - *all* HP supplied init RC files have an associated config file with a
>   variable to control the starting/stopping of a service:

[...]
> An RC script will typically do ". /etc/rc.config", which will source all of
> the files in /etc/rc.config.d, at the top rather than read in just its own
> config file explicitly.  From a system admin POV, it's a damn sight easier
> to manage than the mess Solaris dumps you with.  You can even start using
> RCS/CVS/SCCS in /etc/rc.config.d and *NOT* have to change anything in order
> to prevent lossage.  There is *rarely* a need to edit the RC files directly.

I don't want to see yet another directory of scripts that need to be kept
in sync with the stuff in /etc/rc.d.  In addition to the maintenance issue
is the overhead of .sourcing each one of these little scripts.

Let me propose the following:

Have a section at the head of the scripts with all the configuration
variables, possibly bracketed by specific comments so the contents can be
mechanically extracted.  It would look something like this:

	#!/bin/sh
	#
	# $NetBSD: amd,v 1.2 2000/04/15 21:14:50 tsarna Exp $
	#

	# PROVIDE: amd
	# REQUIRE: portmap mountall ypbind

	# CONFIG
	#
	# This section configures amd and this comment would end up in
	# /etc/rc.conf
	#
	amd_flags=${amd_flags:="-l syslog -x error,noinfo,nostats"}
	amd_dir=${amd_dir:=/amd}			# mount dir
	amd_master=${amd_master:=/etc/amd/master}	# master map
	# ENDCONFIG

	. /etc/rc.subr
	. /etc/rc.conf

	name="amd"
	command="/usr/sbin/${name}"
	command_args='-p -a '$amd_dir' `sed s/#.*$// <'$amd_master'`
	>/var/run/amd.pid'
	required_files="$amd_master"
	required_dirs="$amd_dir"
	required_vars="portmap"

	run_rc_command "$1"


These would be the default settings.  A script would then be run to
extract these variables from everything in /etc/rc.d and deposit the
default values in /etc/rc.conf.  You can then override the defaults by
editting /etc/rc.conf.

> My main concern with NetBSD's rc implementation is the problem of controlling
> what gets started at bootup and what gets stopped when you shutdown.  Having
> two separate directories (/etc/rc.d and /etc/init.d) without adding S/K only
> alleviates one side of the problem.  I'm beginning to think that it may even
> need to be rototilled as the shutdown side of things didn't seem to be very
> well thought through during design/implementation by any of us.

I like the idea of adding an /etc/init.d to hold the primary copies of the
rc scripts and copying/symlinking/hardlinking them to an entry in
/etc/rc.d to enable them.  It's clean and you can immediately tell what's
enabled and what's disabled.  

I don't want to se the S/K stuff which is ugly and a maintenance
nightmare, and I see no need for that or an /etc/shutdown.d since that
should be handled by PROVIDE/REQUIRE.  If it was started on the way up, it
should be turned off on the way down.

Eduardo Horvath