On Tue, 25 Jun 2002, Greg A. Woods wrote:

# [ On Tuesday, June 25, 2002 at 13:24:09 (+0200), Manuel Bouyer wrote: ]
# > Subject: Re: rc.local and rcorder(8)
# >
# > On Sat, Jun 22, 2002 at 10:58:30AM +0200, Martin Husemann wrote:
# > > > making is run unconditionnaly at the end of rc is not that good,
# > > > because there are situations where you may want a rc.d script depend on
# > > > something in rc.local.
# > >
# > > IMHO it is just run for legacy compatibility.
# > >
# > > I'd suggest: remove rc.local from the default install, and at the end of
# > > startup/beginning of shutdown run it, if existent, unconditionally.
# > >
# > > If you have anything depending on something else, you shouldn't put it in
# > > rc.local, but create your own rc.d script for it.
# >
# > Well, it's not always easy to do a rc.d script. For some stuffs, rc.local
# > is really more appropriate.
#
# Huh?  They're both just plain old shell scripts.  If you can do
# something in rc.local then you can write an rc.d script to do it as
# well.  The only significant difference is that in an rc.d script you
# should probably do something intelligible with the first command-line
# parameter.

Perhaps we should have something in /usr/share/examples (never mind that
there are plenty of examples in /etc/rc.d; some more complex than others)?

I have to agree with this statement, but I have to say that others have
seen this coming -- that it's perceived as "easier" to add a local
"temporary" hack to rc.local than to do it the right way and write/modify
an rc.d script (the reason for the quotes is, I hope, obvious).

I'm not altogether crazy about the third-party stuff still using startup
scripts that don't handle a "stop" argument (or, in fact, an argument
at all).  I've grown rather used to being able to say "/etc/rc.d/foo status"
or even "/usr/local/etc/rc.d/foo stop"; there are still some things that
I can't do this with (atalkd and samba (recent!) come to mind).


# Other than third-party programs which expect to install their hooks in
# rc.local and which you don't want to modify to do otherwise, the only
# only things more appropriate for rc.local are those really simple things
# that don't need to be started in any particular order, don't normally
# need to be stopped before a shutdown, and which require just a simple
# one-line entry to invoke, _and_ (this is the most important point) are
# so trivial and unimportant that you don't want to take the few moments
# that would be necessary to write a proper rc.d script.
#
# I.e. rc.local really is just for legacy compatability and silly stuff
# you might want to do with a quick hack on a test machine.

See above, but I think that's the general sentiment, yeah.

				--*greywolf;
--
NetBSD: Unix With Balls.