On Fri, 27 Aug 2004, Joey Morin wrote:
> i figure this is becuase:
> a) some boot-time operations are backgrounded, in this case
> specifically dnsmasq
> b) a 486DX2/66 with 32MB RAM is too slow to allow dnsmasq to
> complete it's boot-time duties before ez-ipupdate is started
> as i said, this doesn't seem to be a problem since ez-ipupdate sleeps for
> 10 minutes after the boot-time failures and tries again, succeeding.
> just curious, am i right about a) above? and if i am, is there a reason
> to do it this way? would it break things to serialize the boot tasks? i
> guess it might slow things down, but it may also allow m0n0 to run more
> reliably on older hardware. that's one of the big reasons i like it to
> begin with...
First of all, "serializing boot tasks" isn't something one can just choose
to do. Most daemons do their own forking so that they don't hang up
init. While there's often some sort of debugging option to suppress this,
it really is just for debugging and not for normal use.
Secondly, much of what processes wait for is I/O rather than computing, so
the more serialized the startup, the slower it becomes *even on fast
machines*. Slowing down boot times on fast machines just to help a small
minority using ancient hardware doesn't seem like a good tradeoff.
The real problem is the lack of a general "dependency" mechanism to handle
sequencing correctly without depending on timing or unnecessary
serialization or resorting to explicit delays. This isn't just a FreeBSD
issue; I've never seen *any* OS that really gets this right.
A kludgy workaround for problems like yours is a two-tiered delay, where
the sleeps are initially much shorter to quicken the response, and then
fall back to longer delays after a certain limit.