Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 88185 - nscd stops responding with nss_ldap
Summary: nscd stops responding with nss_ldap
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-07 13:56 UTC by Jan "Yenya" Kasprzak
Modified: 2016-11-24 15:14 UTC (History)
8 users (show)

Fixed In Version: 2.3.3-65
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-10-06 05:33:18 UTC

Attachments (Terms of Use)

Description Jan "Yenya" Kasprzak 2003-04-07 13:56:52 UTC
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):

How reproducible:
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).

Comment 1 John Koyle 2003-04-18 22:02:19 UTC
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
[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.

Comment 2 Jaggu 2003-05-01 14:41:31 UTC
Ditto...Same problem here. 

My production server went down coz. of this..

Comment 3 Jeff Gustafson 2003-05-02 00:33:41 UTC
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.

Comment 4 Jim Croci 2003-05-12 21:47:43 UTC
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).

Comment 5 Rob Lineweaver 2003-06-02 14:30:54 UTC
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.

Comment 6 Mark Leary 2003-06-19 20:07:32 UTC
I am having the same problem w/rh8... nscd dies, too many open files.

Comment 7 DM 2004-01-28 14:24:44 UTC
Same problem here. Upgrading nscd to 2.3.3 did not help.

Comment 8 DM 2004-01-28 14:27:34 UTC
Same problem here. Upgrading nscd to 2.3.3 did not help.

Comment 9 DM 2004-01-28 14:43:25 UTC
Sorry folks for the double entry. For peacemaking:
I think upgrading to nss_ldap-207-6.i386.rpm helps.



Comment 10 Rob Lineweaver 2004-01-28 14:45:08 UTC
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.

Comment 11 Ulrich Drepper 2004-10-06 05:33:18 UTC
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.)

Note You need to log in before you can comment on or make changes to this bug.