From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803
Description of problem:
After changing the password on our NIS-Server, the client does not use the new password while nscd is active. With deactivated nscd the new passwords are delivered. Restarting nscd gives again the old password. Timeouts in /etc/nscd.conf are the default values (600 sec), but I get the old password even after 3 days
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Change password on NIS Server
2. wait 30 min
3. getent passwd user
4. getent passwd | grep user
Actual Results: "getent passwd user" gives me the old password hash, while nscd is active
"getent passwd|grep user" gives me the new hash, same for "ypcat passwd"
Expected Results: After the 10 minutes timeout I expect to se the new hash values
No information about any problems in /var/log/messages
Output from nscd -d -d -d:
12368: Access Vector Cache (AVC) started
12368: handle_request: request received (Version = 2) from PID 12376
12368: provide access to FD 5, for passwd
On FC3, I suffer of the same symptoms, but with hostnames. It returns old
invalid IPs when resolving hostnames and the cache never gets updated. This
happens with the same version reported above.
nscd simply does not update its cache anymore.
Just got bitten by stale entries in nscd's hostname cache (FC3). This can lead
to a numer of pretty bad problems, so I am increasing the severity.
I'm seeing this too. Was just going to post to fedora-test-list. It seems caches
only get flushed when the files get touched, and not when the TTL has expired.
Here's the post:
We've been seeing nscd cache expiration problems every now and then
like I mentioned a few months back with both passwd and hosts. Has
happened often enough that it's not just a local configuration issue
It seems like positive hits just don't time out, and nscd -i is the only
thing that clears things up. passwd/hosts "never" get touched (we're using
NIS+, customized local install), so the entries don't get invalidated that
way, which might be the reason not that many other people are seeing the
same problem. Another symptom I've sometimes seen is a DDNS host
have an old address for days (until nscd -i hosts). nslookup,
which doesn't go through nscd, shows the current address.
nscd is running with default timeouts (600 secs for passwd, 3600 for hosts)
Will be happy to get data to track this down. I suppose there's no
database dumper that would tell what nscd is actually currently caching and
how old the data is?
I've actually ran nscd for quite some time in debug mode, and the only
situation it flushes entries is touch /etc/passwd and touch /etc/hosts.
At our lab we have the same issue. We are using LDAP authentication, user tend
to change their passwords, and try to access their mail trough IMAP, the imap
server uses the NSCD cache, and oops failed.
As discused in an erlier thread this is a disign issue, nscd was never tought to
be use in this fasion.
We have been able to control this trhough the configuration file. We reduce the
lifetime of the hash tables, set the caches to be NON persisten. (that is right,
no matter how many times you restart the service the cache does not flush unless
this option is enabled.), and set the service to auto restart every 10 minutes.
The overall preformance does not seem to be afected.
This bug has been raised to firstname.lastname@example.org as having possible security
consequences due to stale DNS/auth/etc.
I checked into the upstream cvs a patch which might cure this problem. I don't
know whether this is the case since nobody bothered to provide debug output.
Hopefully we'll have a new rawhide version soon.
nscd-2.3.5-4 has this fix in.
Any chance for an FC3 errata?
Still no RHEL update over a month after nscd fix was found. We're beginning to
doubt weither maintaining our "Enterprise" subscriptions is really worthwhile,
compared to Fedora. What's stability without security and bug fixes?
This bug fix is scheduled for RHEL4 U2, it came too late to be included in RHEL4
Is a rawhide RPM with this fix that will be included in U2 available somewhere?
I'm happily using rawhide/FC4's nscd (only, not the other bits of glibc) on FC3,
since an errata update doesn't seem to be coming any time soon for FC3 either.
You might have luck on RHEL as well. Since the default nscd is pretty much
unusable if you are hitting this bug it's unlikely it's going to make things any
The rawhide/FC4 rpms will not be included in RHEL4 U2. Instead, the patch
(among other fixes collected for U2) will be backported.
If you want to rebuild glibc yourself, the fix is:
Running FC4/rawhide nscd on RHEL4 could work too.
RHEL4 U2 initial glibc testing RPMs that should address also this problem
uploaded to ftp://people.redhat.com/jakub/glibc/2.3.4-2.10/
According to comment #8, this fix has been in rawhide for three months now, but
still now FC 3 update. What's the status?
It is in FC3 testing updates ATM.
This ticket is listed as closed, but there's still no FC 3 update. Is this ever
going to come out of rawhide?
Just got another update saying that a clone of this bug (BugID 164812) was
fixed... But there's still no FC 3 update. I suppose FC 3 will simply become
unsupported soon, and be forgotten entirely.