Subject: Re: re-reading /etc/resolv.conf and threads...
To: J.T. Conklin <email@example.com>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 04/27/2006 21:33:55
On Thu, Apr 27, 2006 at 11:14:19AM -0700, J.T. Conklin wrote:
> We've encountered an interesting problem with long lived server on our
> NetBSD 2.99-ish based appliance and changes to DNS configuration.
> It is my understanding that the best practice is for long running
> processes to call res_init() to reinitialize the resolver library
> when/if /etc/resolv.conf is changed, because on many systems (and it
> appears that NetBSD as among that set) it is not automatically done.
> This works with single-threaded programs, but with multiple threads
> __res_get_state() gets the resolver context from a free list, only
> allocating and initializing a new one if the list is empty. So the
> call to res_init() only reinitializes the global resolver context,
> which is not used. With multiple threads, multiple resolve.conf
> updates, and a very slow nameserver, it's possible for each context
> on the free list to be different. So depending on what thread gets
> what context, you can have completely different lookups. This seems
> ... undesirable.
> Other than running a local caching nameserver and never touching
> /etc/resolv.conf, what's the best practice for reseting the resolver
> context(s) for long lived processes?
There was a long thread about this on dec, 2003 and I may event have posted
a patch to have libc reread resolv.conf when needed (I don't remember).
I think the libc's resolver should take care of this; it's annoying to
have to restart firefox on a laptop because the network changed.
Manuel Bouyer <email@example.com>
NetBSD: 26 ans d'experience feront toujours la difference