> [ On Friday, September 19, 2003 at 07:58:12 (-0700), jon@bullers.net wrote: ]
> > Subject: Re: Booting NetBSD Faster 
> >
> > My one and only datapoint against this is when I put an SSL cert
> > in my Apache config...  My SS20 would spend several minutes waiting
> > for Apache to start before letting me log in then.  Don't know if
> > it was waiting for more key material from /dev/random, or if it
> > was precomputing and encrypting things, but it seemed like forever.
> 
> Well if you know you don't have anything which depends on apache being
> already running when it starts then you can simply arrange to start
> apache in the backgrouns.  There's no need for /etc/rc to wait for it.

Yes you could.  But I was just playing around that day, so I didn't
really care.  Also, if you had bothered to copy the context, you
would see that this was offered as a specific example of where
starting things in parallel *might* be useful.  I also see that
you cut out my comment (made in passing) that fsck is a second data
point for this exact situation.  But your "fix" doesn't work there
does it?

The slightly more general case for apache is that between the DAEMON
and LOGIN "slots" there are a whole bunch of things that don't
depend on each other, and some of them *might* take some time to
get started.

For another example, consider an NTP server that is down, but used
at boot time.  After the server times out during ntpdate, the system
will probably fall back to using it's clock setting, but in the
mean time, several other things could have been started too.  In fact,
if you have a NFS server in the same spot, you might prefer for both
of those timeouts to happen in parallel, cutting your boot time almost
in half.  (Assuming swap, /usr, home directories, etc. are not on
that NFS server.)

> If I'm not mistaken (and no, I haven't tested this, yet), a carefuly
> placed "&" in the appropriate variable setting should do the trick,
> though choosing the exact variable and the exact location will probably
> depend on exactly which rc.d script you're working with.  Perhaps if the
> rc.subr infrastructure had a simpler way to say "start in the background"

So rather than implement a general, useful, workable, and relatively
simple solution, you recommend series of small hacks to work around
it all.  In the cases where a dependency does exist, these
hacks will not work, and you will have to implement the proper
general solution anyway.  I would leave this project in a heartbeat
if that kind of attitude was shared by even a reasonable minority
of the other NetBSD developers.

(In this specific case, apache was killed by a control-c on the
console and restarted later. But yes, it could have been started
"in the background", and things would be fine... until you started
using apache to validate logins or something. 8^)

Jon