Bug 59168 - updatedb eats 90 - 100% CPU
updatedb eats 90 - 100% CPU
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: slocate (Show other bugs)
7.2
athlon Linux
medium Severity high
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-02-01 06:20 EST by Christian Schaller
Modified: 2014-03-16 22:25 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-04 16:59:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Christian Schaller 2002-02-01 06:20:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.0.2 (X11; Linux i686; U;) Gecko/20011226

Description of problem:
I have had this bug occuring from time to time ever since I installed RH7.2.
Suddenly my disk start trashing and the system becomes extremly unresponsive. At
first I thought it must be evolution sending out a rogue process as I felt that
bug always occured while I had evolution running, but today I actually bothered
to wait on the system long enough to open a terminal and run top. It seems the
process updatedb is the sinner here which constantly reported between  90% to
100% CPU usage. Having this process running I killed it after 70 minutes. 

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


How reproducible:
Couldn't Reproduce

Steps to Reproduce:
Haven not found a 100% sure waht to reproduce this bug. Not sure exactly what
triggers it.

Additional info:

I am running a base RedHat 7.2 install + the gnomehide packages.
Comment 1 Bill Nottingham 2002-02-04 15:45:51 EST
Are there any odd messages in syslog related to this?
Comment 2 Christian Schaller 2002-02-04 16:59:36 EST
Tried scanning through many of the logs under /var/log but couldn't find anything. 
Any particular logfile? If so I try and look at it next time this happens.
Comment 3 Christian Schaller 2002-03-10 06:59:15 EST
Seems what triggered this behaviour was a faulty IBM disk. When it expanded as
it got warm the system supposed to keep track of where things got stored failed
to do it job and clusters where lost each time. After setting a fan on the disk
the problem has gone away.

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