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): nscd-2.3.2-4.80 nss_ldap-198-3 How reproducible: Easily. 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. Actual results: After some time the script starts printing numeric UIDs instead of user names. Expected results: "ls -l" printing user name instead of numeric UID. Additional info: 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[29370]: 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 nscd-2.3.2-4.80.6 [root@host conf]# rpm -qa|grep nss_ldap nss_ldap-198-3 [root@host conf]# rpm -qa|grep glibc glibc-kernheaders-2.4-7.20 glibc-2.3.2-4.80.6 glibc-common-2.3.2-4.80.6 glibc-devel-2.3.2-4.80.6 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. See: http://bugzilla.redhat.com/bugzilla/long_list.cgi?buglist=99078
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 latest version. 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.)