[Bug 1110331] Re: nscd no longer needs to be restarted by libc's resolvconf update script

[Thomas Hood]

I have been testing nscd for a while and have discovered, alas, that
although nscd notices when resolv.conf changes — e.g., when it needs to
do a DNS query it uses the correct nameserver address — it does *not*
invalidate its hosts cache when resolv.conf changes. This causes
problems when connecting to VPNs whose nameservers give different
results from those given by external nameservers. I filed a bug report
against nscd in the Debian BTS: bugs.debian.org/700385. The executive
summary is:

* Nscd doesn't invalidate its hosts cache on resolv.conf changes;
* if nscd is supposed to do so then, then please fix the bug;
* otherwise please include a  resolvconf update script in nscd which invalidates nscd's hosts cache.

I wonder if resolvconf should do the nscd hosts cache invalidation
itself, using "nscd --invalidate hosts".

But considering

* nscd is only in universe;
* nscd's hosts cache is disabled by default; and
* nscd — either the binary or the package — should be responsible for handling resolv.conf changes, not resolvconf,

I am reluctant to do so.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1110331

Title:
  nscd no longer needs to be restarted by libc's resolvconf update
  script

Status in “resolvconf” package in Ubuntu:
  Confirmed

Bug description:
  Browsing the eglibc mailing list archives I notice[0] that the eglibc
  resolver has been enhanced[1] such that if /etc/resolv.conf's mtime
  changes then the client is asked to re-initialize the resolver state.
  I haven't tested the code, but if I understand the feature correctly
  it gives us an opportunity to eliminate from
  /etc/resolvconf/update.d/libc the code that restarts nscd after an
  alteration in resolv.conf. That would be a beneficial simplification.
  Ditto for some other resolvconf update scripts.

  Can we take advantage of this eglibc enhancement in order to simplify
  resolvconf update scripts?  Do we want to?

  [0]http://www.eglibc.org/archives/patches/msg00977.html
  [1]http://patch-tracker.debian.org/patch/series/view/eglibc/2.11.3-4/any/submitted-resolv.conf-thread.diff

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1110331/+subscriptions