On Wed, 2009-01-21 at 09:26 -0500, Colin Walters wrote: > On Tue, Jan 20, 2009 at 8:19 PM, Colin Walters <walters@xxxxxxxxxx> wrote: > > > > Both Debian/Ubuntu > > (http://patches.ubuntu.com/g/glibc/extracted/any/local-dynamic-resolvconf.diff) > > and OpenSUSE (http://download.opensuse.org/distribution/11.0/repo/src-oss/suse/src/glibc-2.8-14.1.src.rpm, > > 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: > > > 1) 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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
