From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Description of problem:
I have Fedora Core 2 fully updated running on a VIA EPIA 800 Mini-ITX,
(i686 technically but no cmov so runs i586 kernel, etc.).
I have it authenticating against an LDAP directory and so have nscd
enabled and running.
When I try shutting the machine down (or dropping to single user), as
the various processes and services are stopped, as soon as nscd is
stopped, it becomes apparent that it doesn't actually stop, but causes
enough cpu load that the shutdown process grinds, taking around ten
minutes to stop the remaining processes.
Stopping and starting the nscd service on its own doesn't trigger it,
only in the situation outlined above.
Syslog manages to catch the following in /var/log/messages:
nscd: nscd shutdown succeeded
nscd: 1355: while accepting connection: Invalid argument
nscd: 1700: while accepting connection: Bad file descriptor
nscd: 1700: while accepting connection: Operation not
last message repeated 21075 times
Once the machine gets to single user, I can manually kill the nscd
threads and they disappear, or in the case of a shutdown, the machine
I can also do the same thing with a 'proper' i686/athlon-class machine
and I have yet to see this problem, so it looks related to cpu class,
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot into a runlevel that starts nscd
2. Enter a runlevel that stops nscd; 0, 1 or 6
3. Notice how long the box takes to shutdown after nscd is stopped
Actual Results: If dropping to single user, see the nscd
threads/processes hogging the cpu.
Expected Results: When nscd is reported to be stopped, it should no
longer be running. No other expected results.
There have been many substantial changes in nscd recently.
Can you try FC3rc5 glibc & nscd (2.3.3-74)?
I certainly haven't ever seen something like that.
I've just installed the following packages from the development tree:
I've booted the box between runlevel 5 and 1, and back to 5 again
repeatedly, querying the various tables with getent(1) and id(1) so it
should 'use' nscd.
Normally this would be enough to trigger the bug, but so far has yet
to re-occur, so it looks fixed.