Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 54697 - nscd locks immediately if started with -t 1 and nss_ldap is used
nscd locks immediately if started with -t 1 and nss_ldap is used
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2001-10-16 12:17 EDT by Jure Pecar
Modified: 2016-11-24 10:23 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-04-17 04:41:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2003:325 normal SHIPPED_LIVE : Updated glibc packages provide security and bug fixes 2003-11-12 00:00:00 EST

  None (edit)
Description Jure Pecar 2001-10-16 12:17:18 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.8 i686)

Description of problem:
nscd is started with 6 threads by default (nscd.conf). while debugging some
other problems i started it through strace with -t 1 -d and observed
immediate lockup when a uid/gid should get resolved from ldap.

Version-Release number of selected component (if applicable):
redhat 7.1.94 (glibc and nscd 2.2.4-5)

How reproducible:

Steps to Reproduce:
1. have a ldap based uid/gid resolving and some nfs dir mounted somewhere,
with files/dirs owned by uids from ldap.
2. start nscd with one thread only
3. do a ls -l in the nfs mounted dir

Actual Results:  ls -l locks forever (at least until nscd is stopped) while
ls -ln works. nscd actualy says that the first uid the ls -l should resolve
is not in it's cache, but that's as far it gets.

Expected Results:  i would expect the decrease in number of threads would
only impact peformance, not functionallity. but there's something odd about
it, it works ok if i say -t 2. could this be related to other nscd lockups
people are expiriencing (including me)?

Additional info:

mostly the same as at #54646
Comment 1 Ulrich Drepper 2003-04-17 04:41:30 EDT
This problem should now be fixed in the official glibc CVS sources.  The next
binary we produce should contain the fix.
Comment 2 jmccann 2003-05-20 16:46:44 EDT
I'm seeing this too with NIS+ with the default number of threads.  Will there be
a new binary for RH9?  Or are the glibc+nscd RPMs in rawhide stable enough to
use in production?  Thanks.
Comment 3 Ulrich Drepper 2003-11-04 16:30:58 EST
Try the binaries at


which are supposed to be the next RHL9 errata.

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