Date: Fri, 6 Jan 2006 10:54:44 -0800 From: Brooks Davis <brooks@one-eyed-alien.net> To: Garrett Wollman <wollman@csail.mit.edu> Cc: freebsd-rc@freebsd.org, bug-followup@freebsd.org Subject: Re: conf/90863: [patch] 6.0 boot: name resolution broken for daemon startup Message-ID: <20060106185444.GB2469@odin.ac.hmc.edu> In-Reply-To: <17333.60276.293518.585286@khavrinen.csail.mit.edu> References: <200512310157.jBV1vuCf033689@freefall.freebsd.org> <17333.60276.293518.585286@khavrinen.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--uQr8t48UFsdbeI+V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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@FreeBSD.org> said: >=20 > > 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. >=20 > 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. >=20 > 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 --=20 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 --uQr8t48UFsdbeI+V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDvrzzXY6L6fI4GtQRAgWgAJ9gv1DcNjuYz5/9lW5uDznW65Hn/gCfdtAF D/F1uuPk32YKSsQc9mgdWSI= =hN38 -----END PGP SIGNATURE----- --uQr8t48UFsdbeI+V--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060106185444.GB2469>