Bug 74508 - System freezes for several seconds while slocate.cron is running
System freezes for several seconds while slocate.cron is running
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-09-25 13:11 EDT by Need Real Name
Modified: 2008-08-01 12:22 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 11:39:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2002-09-25 13:11:32 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Description of problem:
Problem Description: System freezes for several seconds while slocate.cron is 

straceing on the updatedb indicate that the occasionally getdents16 took 
several seconds.When this occured all the user level processes froze for a 
while.Running a date command every 2 seconds sometimes took 12 seconds to 
return. It appears that 2.4.18 kernel from kernel.org doesnot exhibit this 
problem.  Is this a known issue?

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

How reproducible:

Steps to Reproduce:
1. run slocate.cron
2. check the date 

Actual Results:  User mode processes stalled for several seconds , e.g : top

Expected Results:  No freeze/ stall

Additional info:
Comment 1 Arjan van de Ven 2002-09-25 13:13:16 EDT
how much ram do you have?
and what kind of disk system ? (scsi/ide, if IDE, is DMA enabled ?)
Comment 2 Need Real Name 2002-09-25 13:22:49 EDT
It is IDE. We run the default prebuilt kernel on the  CD. Is DMA enabled by 
Comment 3 Arjan van de Ven 2002-09-25 13:24:18 EDT
for supported chipset/bios combinations, IDE DMA is enabled.
Use hdparm -i /dev/hda to tell if it's on in your case...
Comment 4 Need Real Name 2002-09-26 08:17:55 EDT
More info about the problem set-up:

->To reproduce the problem faster, we grepped on a large file and pipe it to a 
->DMA is enabled.  128MB one machine/ 256 MB on the other one.

->Disabling the DMA (hdparm -d0 /dev/hda) makes the problem  appear much faster 
with this set-up.

**More info:
 1) replacing ext2 with ext3 file system in the red hat kernel make the problem 

 2) The problem is not reproducable with original (2.4.18-5) kernel (with ext2 
and ext3)

Comment 5 Need Real Name 2003-05-22 10:34:48 EDT
This problem seems to be there with RedHat 8.0 and RedHat 9.0. This bug is 
still in NEEDINFO state. I am not sure what additional info is waited on?
Comment 6 Arjan van de Ven 2003-05-22 10:38:06 EDT
the latest erratum should have some improvements here; but updatedb still is a
bit of a machine pig. Also if ext3 fixes it, great, since ext3 is the default
Comment 7 Need Real Name 2003-05-23 11:31:02 EDT
slocate works on EXT2 and not on EXT3. Why this behvior between EXT2 and EXT3. 
Also we replace RedHat kernel with the kernel from kernel.org fixes the issue 
even on EXT3. 

The similar problem is noticed if we access a huge file or tar a huge archive 
say 200MB instead of using updatedb? Are these problems related?  Any idea how 
to get around this issue? Are you aware of the root cause? Are there any plans 
to fix this? 
Comment 8 Bugzilla owner 2004-09-30 11:39:56 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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