Red Hat Bugzilla – Bug 74508
System freezes for several seconds while slocate.cron is running
Last modified: 2008-08-01 12:22:52 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):
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
how much ram do you have?
and what kind of disk system ? (scsi/ide, if IDE, is DMA enabled ?)
It is IDE. We run the default prebuilt kernel on the CD. Is DMA enabled by
for supported chipset/bios combinations, IDE DMA is enabled.
Use hdparm -i /dev/hda to tell if it's on in your case...
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.
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
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?
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
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?
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/