I followed the discussion on that subject and piked this mail to follow
up, but will address other issues also.

Marc Baudoin <babafou@babafou.eu.org> wrote:
> Luke Mewburn <lukem@cs.rmit.edu.au> wrote:
> > This document describes a proposal for an implementation of
> > /etc/init.d/* scripts for NetBSD. It is based on work and ideas
> > by Luke Mewburn, Matthew Green, and others.
> 
> I have been using rc.local files for a long time now and my
...
> I have a request to make tough.  Please include an fully
> commented EXAMPLE script so that people can easily make their own
> scripts from the ground up.  A README file in /etc/init.d would
> also be appreciated.  Not providing such files is one of the
> biggest criticisms I can make to systems using such a scheme.

A man page, which describes, what and how things should be implemented
in the scripts, would be a good idea. One of the best things in UNIX
is the "central" point of documentation, with the man pages. I think
section 5 file formats are the right place.

...
> Anyway, I like this system and it would be a good thing to
> provided it with the next major release of NetBSD.

I also like it.
...

++ itojun wrote that it will be harder to track problems on startup.

I think with proper logging, maybe enforced by the framework, it shouldn't
be a problem.

++ Darren Reed wrote:
> Any `additions' should be standard across all scripts which are
> NetBSD derived (vs 3rd party) - even if they're null ops so that
> invalid actions always return errors.

And some want to the scripts to fail and some not.  I would follow
"Simon Burge" to have a way to allow silent failures for unsupported
commands. Maybe the scripts should have an additional line "# OPERATIONS"
with a list of all supported commands.

There where also some discussion about a "# BEFORE" line, which I really
think it's required. i.e. I use exchangeable hard disks and will need
different "fstab" to get all automaticly mounted. I can simply write a
script, that checks the disk labels and switch between the set of "fstab"
files, but this must be done before the not critical file systems are
mounted.

++ Nathan J. Williams wrote:
> >  Similar to /etc/rc.sh, but reverses the order of the output
> >  of `rcorder /etc/init.d/*`, and calls each script with `stop'.
> 
> This makes me nervous on a few levels. First, I'm not sure that
> backwards order is really right, although a counterexample does not
> immediately leap to mind. Second, some of the shutdown steps, while
> the opposite of the startup steps, are far from necessary (cf. quota).

See above and empty operation or not implemented and silently ignored.

> Finally, it depends (even more than the startup stuff does) on "foo
> stop" actually stopping the service and not continuing until it's
> dead. I guess for cases like the classic "Shut down the database
> before unmounting the disks" case, the stop script should be smart
> enough to wait until it's really gone, not just exiting after sending
> the TERM signal.

Be careful, the shutdown should always work, there must be a way to
continue, if a part fails to shutdown. For this timeouts are need, an
other line '# TIMEOUT' or a central value? Should the stop be split into
a graceful stop and a force stop?

BTW. I have not found the rcorder command, is this part of 1.4.1?

have a nice day
Bernd Salbrechter