Python and /etc/resolv.conf changes

[Dan Williams]

On Wed, 2009-01-21 at 09:26 -0500, Colin Walters wrote:
> On Tue, Jan 20, 2009 at 8:19 PM, Colin Walters <walters at verbum.org> 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.