Skip site navigation (1)Skip section navigation (2)
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>