The problem with nscd (was RE: NetworkManager & bind)
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().
For example:
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
doesn't work.
Dan
On Fri, 14 Jan 2005, Bill Nottingham wrote:
Dan Williams (dcbw(a)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?
Bill
--
fedora-test-list mailing list
fedora-test-list(a)redhat.com
To unsubscribe:
http://www.redhat.com/mailman/listinfo/fedora-test-list