erh@nimenees.com wrote:

> 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?

From rc.subr:

	# 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
> configure?

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.

Simon.