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.
First Last Prev Next    This bug is not in your last search results.
Bug 78695 - nscd quits servicing requests
nscd quits servicing requests
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency tree / graph
 
Reported: 2002-11-27 13:10 EST by Marc Wallman
Modified: 2016-11-24 10:22 EST (History)
5 users (show)

See Also:
Fixed In Version: 2.3.3-65
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-06 02:10:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

  None (edit)
Description Marc Wallman 2002-11-27 13:10:45 EST 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827

Description of problem:
NSCD quits servicing requests on one of our imap servers. When this happens, the
server becomes totally unusable, the load starts to skyrocket, and any processes
waiting on a request from nscd simply wait and do not exit (e.g. we keep
spawning new imap processes until we hit the maximum number specified in the
xinetd config file). The problem tends to occur on weekday mornings as our
server usage begins to increase. Under normal conditions, the load on this box
is always under 4.

An strace on a command like ps -l shows that the command is waiting on to read
from the nscd socket in /var/run. The problem occurs with great frequency--every
morning before I disabled nscd. All packegs on our box are 100% up to date. An
strace on nscd shows that the application is waiting on a read (of what I don't
know since I have only run strace after the nscd process had hung).

The problem occured with both nscd-2.2.5-42 and nscd-2.2.5-39.

A similar problem appears to have been reported in bugs 17519 and 13308.

Version-Release number of selected component (if applicable):


How reproducible:
Sometimes

Steps to Reproduce:
I can't reproduce the conditions, but when it runs in production it happens
regularly--almost every weekday between 10am and 12:30pm.

Additional info:

Hardware info:
CPU: 2x1.26Ghz PIII
RAM: 1Gb
Disk: 2x36G (Raid 1), 34G of SAN storage accessed via a Qlogic 2300 HBA
Comment 1 zweers 2003-03-26 14:28:04 EST 
This problem should be a higher priority.

I've noticed a similar problem on two of our servers.  We are converting our
authentication over to use LDAP.  If the LDAP servers disappear for too long a
period of time, nscd stops responding at all, which in turn locks up the server.

This is a very serious problem as it can effect production environments and can
quickly cause what should be a simple problem to bring down every server.

I did not see if the original problem included interactions with LDAP, but I
wonder if it also depends on a remote server.
Comment 2 Eric Doutreleau 2003-06-11 05:32:10 EDT 
I got exactly the same problem.
the nscd die and i have xemacs processes that eat all memory of my server.
Comment 3 Adam Lynch 2003-09-10 11:25:03 EDT 
We're seeing this issue as well. We're running nscd 2.2.5-43 and OpenLDAP
2.0.27-2.7.3. 

All system processes go into sleep, no new processes are spawned. System is, for
all intents and purposes, locked. The only way for us to re-engage the system is
a reboot.
Comment 4 Ulrich Drepper 2004-10-06 02:10:48 EDT 
(The component was wrong, it should have been glibc not nscd, this is
why this bug went unnoticed.)

There have been countless of c hanges since 7.3 and glibc 2.2.5.  With
glibc-2.3.3-64 and up I don't expect any problems even with the
nss_ldap module anymore.  Upgrade to this or a later version when
available and retest.  Open new bugs for all negative findings.  This
bug is outdated and therefore I close it.
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.