Bug 448916 - nscd sucking 100% cpu
Summary: nscd sucking 100% cpu
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 9
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-29 14:00 UTC by Neal Becker
Modified: 2008-08-03 03:21 UTC (History)
4 users (show)

Fixed In Version: 2.8-8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-08-03 03:21:44 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
strace output (6.91 KB, text/plain)
2008-06-05 12:31 UTC, Brian Long
no flags Details

Description Neal Becker 2008-05-29 14:00:08 UTC
Description of problem:

I have now several times experienced nscd using 100% cpu.  No idea what triggers
this.

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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Brian Long 2008-06-05 12:30:47 UTC
I can confirm this just took place on my F9 laptop.  I will attach a small
snippet of strace output.

Comment 2 Brian Long 2008-06-05 12:31:12 UTC
Created attachment 308430 [details]
strace output

Comment 3 Ulrich Drepper 2008-06-12 17:52:24 UTC
(In reply to comment #1)
> I can confirm this just took place on my F9 laptop.  I will attach a small
> snippet of strace output.

The log only shows the first thread, not the others.  There are also no
timestamps so I don't know the scale.  But this looks quite normal.  There are
incoming requests and the epoll mask is modified.

Comment 4 Simo Sorce 2008-07-15 22:06:42 UTC
I had a virtual machine dieing under nscd 99% load for many many minutes, as
soon as I did an 'service nscd restart' the machine resurrected, and nscd
stopped using 99% cpu.

what kind of information do you need to analyze this problem ?
is strace sufficient?
attach gdb ?

Comment 5 Ulrich Drepper 2008-08-03 03:21:44 UTC
Should work nicely in current version.


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