In some email I received from Luke Mewburn, sie wrote:
> Darren Reed writes:
> > "reload/restart" would be another useful one.
> 
> `restart' is built in by default (does `stop' then `start', unless
> otherwise specified). `reload' is only supported if asked for, because
> it doesn't make sense in all contexts.

Agreed.

> > > 	* Implementers should be able to add extra actions to a
> > > 	  script (e.g, `reload', `debugon', etc) fairly easily.
> > 
> > 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.
> 
> ???. if you do /etc/init.d/foo blah and foo doesn't support blah,
> you'll get an error; this is what i'd expect. do you want every
> script to support every option that another script needs (e.g,
> `named' might support querylog, debug, etc)?

Yes.  The actions should be supported by all scripts.  They may do
nothing or they may do something.  At least that way when you want
to do something like "for i in /etc/init.d/*; do $i querylog; done"
you don't get a bunch of crap from scripts which don't support that
particular switch.  I think things like the cachefs.daemon script
on Solaris7 are bad examples (that particular script has been written
in such a way that it does start but not stop).  The S99dtlogin is
another bad example because it supports a bunch of switches which
are otherwise unused elsewhere (reset/update_printers/get_server_pid).
There should be some semblance of orthogonal design across all the
scripts.

> > > 		    a) prior art (cf. SYSV), and people are used to running
> > > 			/etc/init.d/foo start
> > 
> > Or /etc/rc2.d/foo start
> > And what about /etc/rcS.d ?
> 
> `prior art' to me is solaris/irix; deal with it ;-).  if you want rc2.d
> or rcS.d because that's what you're used to, then MAKE A SYMLINK!

Well, Solaris has /etc/rc[012356S].d so nerh.  Each of the run levels
is also different in terms of what is started, etc.  You don't want to
go the extra step and create a "RUNLEVEL" tag in your scripts, do you ?
*poke*

[...]
> faststart is a `backdoor' just for the startup scripts, because we
> `know' that the process won't be running so we don't waste time doing
> the `ps' check. if a user does `/etc/init.d/foo faststart' when foo
> is already running and then they get screwed, THATS THEIR FAULT, because
> it's not supported `clueful' behaviour post-boot.

To me it sounds like you're saying "faststart" should be our default startup
method, here, which I think is wrong.

[...]
> > On the whole good, but I've got one major criticism:
> > 
> > in an effort to not piss anyone off (too much) there's too much fence
> > sitting being done.  I don't mind the /etc/rc still being supported
> > (the everything in one script version) but the rest is of concern.
> > There's an /etc/rcX.d which gets used sometimes and an /etc/init.d
> > which also gets used sometimes.  It's possible to have a /etc/rcX.d
> > populated but then ignored by a script which independantly interrogates
> > scripts in /etc/init.d.  From a featurism point of view, sure, it's
> > great that we've got all these features, but I think these two are
> > competing with each other and offer no real long term benefit.  We
> > need to pick one and go with it.  I think this is trying to be everything
> > to everyone and ultimately we'll lose.
> 
> but you're asking for stuff that's effectively fence sitting as well!

Well, I'd go for sitting on less fences, if that makes sense :)  Personally,
I like the idea of supporting /etc/rc as well as the init directory thing,
but do we need to have multiple init directory based things ?  I mean, it's
not like we're trying to turn NetBSD into Linux, is it ?

Darren