[ On Thursday, December 2, 1999 at 11:03:05 (+1100), Luke Mewburn wrote: ]
> Subject: take 2; which way should we go for /etc/rc...
>
> The questions are:
> 
> 	1. Which method do we ship with enabled by default?
> 		I'd argue for b) or c), possibly supporting d) or e),
> 		and strongly against f).

The biggest problem with all of this is that it's trying to do way too
much and to sit to squarely on the middle of the fence/road!

Perhaps there should be alternatives available as options, but I don't
really think the added complexity is necessary since it makes every
sysadmin's life more difficult while the separate maintenance of
optional startup/shutdown mechanisms could apparently be managed already
by those existing developers who are firmly in one camp or another.

> 	2. Do we support the other methods (e.g sample scripts in
> 	   /usr/share/samples/rc/) such as rc.sysv.sh if we choose
> 	   rc.sh.
> 		I'd say `yes', because there's no real harm in
> 		giving people the choice.

NetBSD really must support SysV-style "start/stop" scripts -- it's the
only sane way to control stuff installed by packages.

However we'll see that inevitably there'll be growing requirements to
more tightly integrate package stuff with /etc/rc stuff and it really
does not make sense to set "foo_enable=no" in /etc/rc.conf only to then
run "/usr/pkg/etc/rc.d/foo start".  It would seem to me that this trend
points firmly in the direction of going 100% with "start/stop" style
scripts for the native system too.  After all what happens when the base
system is packaged up into a series of pkg_* blobs?  Why shouldn't they
be realatively easily interchangable with third-party blobs?  In fact
I've already got my own production "release" of NetBSD modified to look
in /etc/rc.d at the end of /etc/rc (and prior to /etc/rc.local).

I can share that my experience with trying to use /etc/rc.d/foo
"start/stop" scripts in combination with /etc/rc.conf "foo_enable=yes"
controls is totally unmanageable in any production scenario where more
than two or three machines are managed in sync.  Even with enough magic
to make a tri-state decision tree that attempts to always do the right
thing is going to only make things more complex than necessary.  I.e. I
think the original requirement stated as "* Control over a function via
/etc/rc.conf (rather than via the existance of a file/link in
/etc/rc*.d)" is a very bogus requirement if "start/stop" style scripts
are to be used.

I think I've already mentioned elsewhere in this thread my dislike of
"generated" script too.  What a maintenance nightmare that could end up
being!  The best thing is not to even create the opportunity to have the
same procedure defined in multiple places.  Creating a list of scripts
to run is the best alternative to having their names define their
startup order.  Whether that list is generated into an iterative script,
or created as a series of links in a control directory, by some kind of
dependency maintenance tool, or not, doesn't really worry me.

A SysV run-level style state machine for grouping startup and shutdown
procedures is perhaps not necessary provided that there's some other
means of defining dependencies.  Howerver I would point out that a state
machine of this type does make it easy to define dependencies in a way
that's totally independent of the startup/shutdown procedures
themselves.  Whether this is a good thing, or not, is another question!  ;-)

BTW, if one uses shell glob ordering of filename expansion as the way to
control script execution there are a multitude of ways of achieving the
flexibility of the old SysV-style scheme without having to use the ugly
naming conventions that were forced on SysV by the old filesystem and
feature-free test(1) command.  For example there could be an
/etc/rc-start.d/ and /etc/rc-stop.d/ directory instead of
/etc/rc.d/SnnFoo and /etc/rc.d/KnnFoo links.  Instead of using the "Snn"
or "Knn" prefix to determine what's runnable vs. what's not one should
also simply do something like this:

	for script in /etc/rc-start.d/* ; do
		if [ -x $script ] ; then
			$script start
		fi
	done


One other feature of a SysV-style init that is perhaps worth discussing
in this context is its ability to re-start a program that should always
be running.  Now of course in later generations of SysV this feature was
intended to be migrated to a separate sub-system (SAC) for various
reasons.  Indeed the basic idea could be implemented in daemon(3) itself
by creating a parent control process, or in the "start/stop" script in
much the way Squid's RunCache script works (complete with the
kill-parent hack!  ;-).  However I think the fundamental idea is that it
is valuable to have a "process watcher/controller" feature that is
*integrated* directly with the system startup/shutdown procedures.


Lastly I'd like to re-iterate someone else's concern for good logging
and reporting.  I think it's critical during the startup and shutdown of
the machine for there both to be a complete log of each operation
(including any abnormal or debug messages associated with each
operation), as well as a very good interactive indication to the
operator of which operation is about to *start* (i.e. not when it's
complete, but when it first starts -- one of the most frustrating things
about traditional *BSD behaviour is that one has to search almost
linearly through the scripts to find out what program might have hung or
otherwise failed if something goes wrong).  Ideally I'd like to see at
least one line of output on the console during normal startup (and
shutdown) for every daemon that's started (and stopped), with the first
part of that line printed before the daemon is started, and the second
part printed after it has successfully detached itself and gone into the
background.  It's not important that all the output might scroll off a
small screen (though FreeBSD-style scrollback on consoles that could
support it would be a tremendous boon!), but rather that there be enough
information and context on the screen at the time something breaks to
know what broke/stuck/whatever and hopefully why.  It might even be nice
to pass the "boot -v" flag on to "init" so that it could tell startup
scripts to be verbose too.


PS:  Yes, the ".d" suffix on a directory name is somewhat superfluous,
however if you have an /etc/rc script then you have to call the
directory something else and giving indication in the name that it
really is a directory seems to make the best sense!  ;-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>