Bug 54697 - nscd locks immediately if started with -t 1 and nss_ldap is used
Summary: nscd locks immediately if started with -t 1 and nss_ldap is used
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-10-16 16:17 UTC by Jure Pecar
Modified: 2016-11-24 15:23 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2003-04-17 08:41:30 UTC

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 05:00:00 UTC

Description Jure Pecar 2001-10-16 16:17:18 UTC
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 08:41:30 UTC
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 20:46:44 UTC
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 21:30:58 UTC
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.