The problem with nscd (was RE: NetworkManager & bind)
dcbw at redhat.com
Mon Jan 17 04:47:29 UTC 2005
Bill & everyone,
Here's the problem. 'nscd -i hosts' isn't adequate for all cases.
Specifically (and you can argue about its relevance), nscd doesn't
interrupt in-process resolution calls and return current information
immediately. Instead, if /etc/resolv.conf gets changed from underneath
'nscd' and you call 'nscd -i hosts', an app like Mozilla will sit there
until it times out because nscd is too dumb to deal with changed
information in the middle of a gethostbyname().
1) Stick bogus information in /etc/resolv.conf
2) service nscd start
3) nscd -i hosts (to clear all previous cached hosts)
4) Fire up mozilla, "www.google.com"
(mozilla will sit there resolving as the DNS servers are incorrect)
5) correct /etc/resolv.conf with good DNS servers
6) nscd -i hosts
7) WAIT FOREVER (15 - 20 seconds)
Using a caching nameserver, and restarting the nameserver, works
correctly, every time, all the time. Try getting something (/Anything/)
past Uli, let alone something with the name resolver.
Note that killing nscd and restarting a fresh copy doesn't work either.
Server-types and those people who don't actually use a desktop may argue
that this delay is acceptable, but its not, even if it occurs 10% of the
time for 10% of the users.
Furthermore, I've run into cases where just 'nscd -i hosts' is inadequate,
as I did when I was testing to make sure I knew what I was talking about
here. I had an nscd running, copied over a bogus /etc/resolv.conf, and
did 'nscd -i hosts', but apps could still resolv names when clearly they
should not have due to the bogus resolv.conf and the invalidated hosts
cache. nscd simply doesn't work well enough, caching-nameservers do.
Were these problems in nscd/glibc corrected, we'd love to switch back to
nscd becacuse its simply less complicated, which is bonus. But not if it
On Fri, 14 Jan 2005, Bill Nottingham wrote:
> Dan Williams (dcbw at redhat.com) said:
> > It uses bind in a caching-nameserver functionality and named should
> > _not_ be turned on my default in this configuration. Use of bind as a
> > caching nameserver was done to work around deficiencies of nscd and
> > glibc and should allow user applications to be aware of changes
> > to /etc/resolv.conf faster, since the applications actually just talk to
> > 127.0.0.1 for the nameserver, and its the caching-nameserver that
> > actually does the heavy lifting when /etc/resolv.conf changes since
> > glibc isn't up to the task.
> Why can't this be solved with nscd and use of 'nscd -i hosts' when
> resolv.conf changes, out of curiousity?
> fedora-test-list mailing list
> fedora-test-list at redhat.com
> To unsubscribe:
More information about the test