Subject: re-reading /etc/resolv.conf and threads...
To: None <firstname.lastname@example.org>
From: J.T. Conklin <email@example.com>
Date: 04/27/2006 11:14:19
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
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?