Subject: Re: /etc/rc.d evaluation.
To: None <email@example.com>
From: Simon Burge <firstname.lastname@example.org>
Date: 04/26/2000 09:02:27
> On Tue, Apr 25, 2000 at 01:29:41PM -0700, Greywolf wrote:
> > >> we could built the 'test' command into sh <<
> Wasn't someone doing this already?
This has been done - around two weeks ago. For the pmax case, it
chopped rc startup time by about third.
> > 5. sh xdm restart passes its args in as "run_rc_cmd xdm restart reload".
> > This is a bad assumption. Once you start it, why are you HUPing
> > it?
> That was looking a bit funny to me too. Anyone know what's with it?
# run_rc_command arg [supported_args]
and by default "supported_args" is the list of "start stop restart
rcvar". Adding the reload at the end means that it's also a supported
arg, and is handled by sending sig_reload which defaults to HUP. Not
quite intuitive - maybe "supported_args" should be handled by another
variable instead of being passed as an argument to run_rc_command...
> > 6. sh network stop does not take down the network interfaces. This is
> > especially bad for rc testing. As I *always* do when I'm running
> > something with which I'm not familiar, I test from single-user
> > mode, and I run "sh /etc/rc". I got to the "network start" part,
> > and the ifconfig hung trying to configure an interface that was
> > still up. "sh network stop" did not take the interface down.
> > "network" needs an "unconfig" or "down" arg.
> This was discussed before. The problem with having it ifconfig down
> the interfaces is that you can cause the shutdown sequence to hang.
> For instance, if you're shutting down to single user and you're NFS
> mounting everything. ifconfig definitely shouldn't hang if the interface
> is already configured. It doesn't for me. How exactly is it trying to
I still thing that using a "shutdown" argument is the way to go for
/etc/rc.shutdown. I send something to tech-userlevel about this - I'll
follow that up there with a BCC here...
> > 7. xdm (again) still manages to start before rc is done, thus
> > causing getty to start AFTER the xconsole pops up. Getty then
> > thinks that /dev/console is in use and complains every 30 seconds
> > about restarting too quickly.
> This would require some changes to init to start some stuff before
> gettys run and some stuff after. This shouldn't be too hard, just need
> to define something. How about init runs /etc/rc again but gives it an
> "aftergetty" argument?
As Ignatios Souvatzis mentioned, the amiga handles this ``properly'' by
having the X server shut out getting while it's running. Ultrix has the
same behaviour - someone with wscons knowledge needs to whack on it to
fix it. I'm not a NetBSD X user - someone else want to file a PR who
has seen this behaviour?
> > 8. If it starts from /etc/rc, there should be a mechanism in place to
> > preserve the original output style. This is purely cosmetic,
> > but I think it's much nicer to see:
> eh, whatever. go for it.
> > Perhaps a check could be done to see if it's being run from
> > the command line or from /etc/rc.
> or a variable set (like _rc_fast_run). "_rc_singleline_output"?
I can see problems here with the current implmentation because rc order
doesn't guarantee the order that commands get executed if they meet the
PROVIDES/REQUIRES requirements... I can't think of something easy to
handle this off the top of my head.