Subject: Re: Proposed rc.d changes....
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Greg A. Woods <>
List: tech-pkg
Date: 05/01/2000 21:39:54
[ On Monday, May 1, 2000 at 23:36:52 (+1000), Luke Mewburn wrote: ]
> Subject: Proposed rc.d changes....
> 4. Supporting pkgsrc rc.d scripts

I've already posted this basic half-baked proposal spread amongst
several other messages over the past month:

  - look for a list of optional directories where rc.d-style scripts can
    be found (eg. /usr/pkg/etc/rc.d, /usr/local/etc/rc.d, etc.).  For
    example with "more_rc_d=/usr/pkg/etc/rc.d" in /etc/rc.conf, do this
    in /etc/rc:

	for _rc_d in /etc/rc.d ${more_rc_d} ; do
		if [ -d $_rc_d ]; then
			_all_rc_d_files=$_all_rc_d_files $(echo ${_rc_d}/*)

	for i in $(rcorder ${_all_rc_d_files}) ; do
		run_rc_script $i start

  - just as in the base system (;-) install the original scripts in
    /usr/pkg/init.d and "enable" them by hard-linking into /usr/pkg/rc.d

  - make sure that missing PROVIDE *and* REQUIRE comment lines cause
    rcorder to list the script last under the assumption that all
    critical system scripts will have the proper settings and that
    add-on package scripts without should normally be run last.   Note
    that I can't reproduce a problem with this right now on my
    development system, but I don't remember off-hand exactly what I
    might have changed to make it work.... :-)

  - add a command-line flag to "pkg_add" that will enable a startup
    script by creating a hard-link from the script installed in
    $PREFIX/init.d to $PREFIX/rc.d (and also do other things)

  - if the package's startup script needs configuration information then
    get that from a correspondingly named file in $PREFIX/rc.conf.d

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

(see the third point above)

There shouldn't be any requirement to ever edit any third-party scripts.
They should just work to the same extent that they'd work in any other
arbitrary system that uses similar startup scripts.  This is a strong
argument against the "shutdown" parameter and any "fast" or "force"
prefixes or whatever.  Such things should be done in some other way,
such as environment variables.

							Greg A. Woods

+1 416 218-0098      VE3TCP      <>      <robohack!woods>
Planix, Inc. <>; Secrets of the Weird <>