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@xxxxxxxxxx) 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@xxxxxxxxxx > To unsubscribe: > http://www.redhat.com/mailman/listinfo/fedora-test-list >