On Wed, 2009-01-21 at 09:26 -0500, Colin Walters wrote:
On Tue, Jan 20, 2009 at 8:19 PM, Colin Walters walters@verbum.org wrote:
Both Debian/Ubuntu (http://patches.ubuntu.com/g/glibc/extracted/any/local-dynamic-resolvconf.dif...) and OpenSUSE (http://download.opensuse.org/distribution/11.0/repo/src-oss/suse/src/glibc-2..., resolv.dynamic.diff) ship a patch to glibc which stats() resolv.conf. We do not.
Thinking about this a bit more this morning on the shuttle, there's a strong argument that this is a glibc bug, and that the stat() approach is a correct fix, if not necessarily the most ideal one. That argument is simply that glibc is caching data without a mechanism for invalidation; and a cache without invalidation is always a bug.
This was discussed with the glibc maintainers a long time ago, and was rejected for various reasons (see below). Their answer at the time was to use "lwresd", a lightweight caching nameserver, or nscd to provide this functionality. This was back in 2004, so perhaps things have changed, and maybe it's time to strike up the conversation again. However, I suspect the answer is still "use nscd".
Dan
-------------------------------------- On Fri, 2004-06-04 at 07:48 -0700, Ulrich Drepper wrote:
Dan Williams wrote:
- make glibc stat() /etc/resolv.conf on every call that does name
lookups 2) make glibc re-read /etc/resolv.conf every time something does a name lookup 3) use nscd instead, and modify ncsd to do either (1) or (2)?
None of this is an option. There is no way we are going to make everybody pay the price for the needs of a few people who wants everything to happen automatically.
The solution is to use nscd and have some external code explicitly flush the cache with
service nscd reload
This is already possible for, I guess, 5-6 years.