conf/90863: [patch] 6.0 boot: name resolution broken for daemon startup

[Brooks Davis]

On Fri, Dec 30, 2005 at 09:22:44PM -0500, Garrett Wollman wrote:
> <<On Sat, 31 Dec 2005 01:57:56 GMT, Doug Barton <dougb at FreeBSD.org> said:
> 
> > First, if you're sure that the problem is with the bge interface,
> > I would prefer to see the problem fixed generically there, rather
> > than in rc.d/named.
> 
> It's not a problem with bge(4), it's a general problem with network
> interfaces that take a long time to bring the link up after it is
> initialized.  (I expect to have the same problem with ti(4) on a
> machine I'm upgrading right now.)  In this particular case I'm willing
> to wait forever, since the machine can't do anything useful until it
> has network, but that would be unacceptable for the general case.
> Ordinary workstations using DHCP don't see this, because you obviously
> can't get a lease until you can communicate with the DHCP server.
> 
> What I'd like would be to have a "don't fork until you're really
> ready" option for named (or even better, for that to be restored as
> the default behavior); servers without a local resolver don't have
> this problem, because the stub resolver will retry requests that don't
> elicit a response.  I think that's a superior solution to anything
> that requires explicit configuration on the part of the sysadmin.

On the whole, daemons should operate on the assumption that the network
will take an arbitrrarily long time to come up and that it may come
and go at any time.  A user should be able to boot their laptop while
on an airplane, suspend to disk for landing, boot up again and aquire
a network connection, and have all their daemons work correctly.
Likewise, a copy of FreeBSD running on a virtual server should support
being suspended, copied to a different datacenter, and coming back up
with a new addresses.  Obviously we're not there yet in a number of
areas, but this is where we should be heading and we can work on
server/libc behavior in advance of the kernel actually working.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20060106/cbd27a62/attachment.bin