Description of problem:
On my system, nscd sometimes stops responding to new queries, and returns
only cached ones.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Local directory /export/home, with ~2200 subdirectories (each one owned
by different user, users in LDAP directory on another RedHat 8.0 server)
2. Run the following command:
for i in /export/home/*; do ls -ld $i; done
3. Wait till "ls -l" does print owner UIDs instead of owner names.
After some time the script starts printing numeric UIDs instead of user names.
"ls -l" printing user name instead of numeric UID.
When I stop the script and restart nscd ("service nscd restart"),
the ls -ld /export/home/<dir> returns good login name even for a directory
for which the above script returned only numeric UID.
The server is Red Hat 8.0, SMP (dual athlon-MP).
I believe this is actually related to the issue I'm having. With the latest
glibc/nscd updates nscd keeps making connections to the LDAP Directory and
eventually causes LDAP to quit responding when it runs out of file descriptors:
Apr 18 15:37:28 host slapd: warning: cannot open /etc/hosts.allow: Too
many open files
A quick netstat -an|grep 389 shows hundreds of connections to LDAP from the host
running nscd. Restarting nscd on the nss_ldap client/host closes all the
connections and the LDAP directory immediately begins servicing requests again.
Here's the relevant package info:
root@host conf]# rpm -qa|grep nscd
[root@host conf]# rpm -qa|grep nss_ldap
[root@host conf]# rpm -qa|grep glibc
NOTE: This system functioned fine untill these updates were installed recently.
It is a RH 8 system with all the latest patches installed.
Ditto...Same problem here.
My production server went down coz. of this..
Okay... I just ran into this problem too! Even takes out sshd which is really
bad. Did know what was going on at first. Left myself logged in as root and
happened to do a 'ls'. Restarted nscd and everything started working again.
This is really bad... I just turned off nscd for now.
We are having the same problem. SSHD is taken down as well. LDAP authorization
is not falling back to files as per nsswitch.conf and /etc/pam.d files. We are
using RH Linux 8.0 with the latest errata (incl. nscd-2.3.2-4.80.6).
Just wanted to add a lame "me too!" to this bug. Started seeing problems on my
LDAP server when I upgraded it to RedHat 8.0 + updates. Even with
/proc/sys/fs/file-max at 157,280 the server runs out of file descriptors
periodically if I do not restart nscd on the clients on a regular basis (and
eventually restart the ldap service).
lsof | grep slapd | wc -l
returns a huge number.
Please contact me if you need more information on the problem. My setup is
similar to the folks above.
I am having the same problem w/rh8... nscd dies, too many open files.
Same problem here. Upgrading nscd to 2.3.3 did not help.
Sorry folks for the double entry. For peacemaking:
I think upgrading to nss_ldap-207-6.i386.rpm helps.
For what it's worth, Fedora Core 1 does not seem to have this issue. I've been
running nss_ldap & nscd for over a month now on a Fedora box without any increase
in the output of:
lsof | grep nscd | wc -l
And no need to restart nscd on a regular basis.
The nss_ldap module has problems which certainly require using the
As for nscd, use 2.3.3-65 which has many improvements. Use this
version from rawhide (soon FC3) and retest. Adjust the table size in
/etc/nscd.conf appropriately for huge installations.
If there are still problems, open a new bug. I'm closing this one
since I don't know of any problem after the last rush of changes after
FC2. Arguing for backports to FC2 or even FC2/RHL9 is useless. You
should be able to use the current glibc on FC2 and possibly FC1
system's though. Back up before testing, though.
(And in case you wonder why nobody cared so far: the nscd component
should never have existed. Always file nscd problems as bugs for the
glibc component. Nobody knew about the nscd component.)