Bug 150748
| Summary: | nscd cache does not expire its caches? | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Frank Mueller <fmuel> |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED RAWHIDE | QA Contact: | Brian Brock <bbrock> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | aleksey, drepper, hans, irilyth+redhat, jjneely, joshkel, mjc, ntroncos, pp |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 2.3.5-4 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-07-25 17:05:25 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 164812 | ||
|
Description
Frank Mueller
2005-03-10 07:00:25 UTC
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 secalert 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 U1. 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 worse :-) 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: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/nscd/connections.c.diff?cvsroot=glibc&only_with_tag=fedora-branch&r1=1.55.2.7&r2=1.55.2.8 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. |