Bug 102722 - Updatedb slows my laptop down
Updatedb slows my laptop down
Product: Red Hat Linux
Classification: Retired
Component: slocate (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Brock Organ
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2003-08-20 06:19 EDT by Julien Olivier
Modified: 2007-04-18 12:57 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-15 14:38:13 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 Julien Olivier 2003-08-20 06:19:05 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703

Description of problem:
I use edhat 9 on my laptop and about every day I've got the same problem: it
becomes very slow once in the morning for about 5 minutes. AThe top command
immediately identified the problem: cron runs the updatedb command every
morning. This is not bad per se but it's bad because I can hardly use my
computer when it updates the database.

So, I have a few questions:
 - Is it really necessary to keep the slocate database up to date automatically
? Does the gnome-search-tool use it ?
 - If it is necessary, isn't there a way to make it run in a more acceptable way
? I mean, for example, make it run slower or "cut" the process and run each
"packet" when the computer is not much used.

Thanks for trying to solve this problem.

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

How reproducible:

Steps to Reproduce:
2.updatedb starts

Actual Results:  You can't work anymore for about 5 minutes

Expected Results:  Go on working :)

Additional info:

I know there are solutions to that problem like removing slocate.cron from
/etc/cron.daily. But that's not what a "normal" user will do.
Comment 1 Bill Nottingham 2003-08-20 15:23:42 EDT
Without putting lots of 'sleep()' calls in the code itself, the way it thrashes
the disk is not really fixable.
Comment 2 Julien Olivier 2003-08-21 04:53:14 EDT
Excuse me if I'm being very naive there but... why not put lots of [optional]
sleeps in the code then ?
Comment 3 Bill Nottingham 2003-08-21 11:23:31 EDT
It's hard to come up with a good tuning value for how to do it. What's probably
best is to change the cron script to run at a time where you're not using the
Comment 4 Julien Olivier 2003-08-21 19:08:07 EDT
Of course that would be a solution but... like most people, I guess, if my
computer is up then I'm actually using it. I mean it's not a server so I use to
unplug it when I'm finished. I don't blame you for not finding a valid solution
to my propblem because I myself have tried hard to fnd a solution but I just
can't come up with something perfect.

Anyway, I think it's worth trying.
Comment 5 Michael Lee Yohe 2003-08-22 11:38:57 EDT
You can simply remove the cron.daily task so that you have to manually update
the database if you want up-to-date results.

# rm /etc/cron.daily/slocate.cron

Alternatively, if you do not use locate to quickly find files on your machine,
you can go ahead and remove the package.  Either way, the cron.daily entry
disappears and your problem is solved.

# rpm -q --whatrequires slocate
no package requires slocate

Since no package requires slocate, it should be safe to remove.

# rpm -e slocate

Comment 6 Julien Olivier 2003-08-23 08:27:22 EDT
There are 2 problems with this solution.

 1) It's not an "out-of-the-box" solution. Meaning that you have to know that
slocate is causing this and then to fix this yourself. Very few people will do
this effort or even be able to identify the problem.

 2) It seems that gnome-search-tool doesn't perform a live search but uses the
slocate database. At least, I can't find newer files using it after removing
slocate cron job.

Here's my humble proposition to fix this problem:

 1) Configure crond so that it runs the slocate job at something like 3am. If
the job wasn't run at 3am because the computer was down, don't run it in the
morning, just ignore it.

 2) Fix the gnome-search-tool so that it doesn't use the slocate database but
performs a live search instead. At least for user-land searches, which shouldn't
take too long anyway.

What do you think of this idea ? Do you think it would be too much work ?
Comment 7 Julien Olivier 2003-08-23 09:21:48 EDT
I've just downloaded the latest version of gnome-utils and I looked at the code.
In fact, gsearchtool has a "quick search" mode which uses "locate" and a
"normal" mode which uses "find".

That means that if you remove the slocate package, it will fall back to "find".
But you also can keep slocate installed and configure gsearchtool to default to
"find" using the "/apps/gnome-search-tool/disable_quick_search" gconf key.

All that to say that there are in fact 2 better solutions:

 - Whether don't install "slocate" by default for desktop installations.
 - Or make "/apps/gnome-search-tool/disable_quick_search" to TRUE by default doe
desktop installations (I agree that this is not an updatedb-related problem in
this case).

But I guess it's becoming a more general bug report, and I should probably just
ask that on the mailing list instead, shouldn't I ?
Comment 8 Bill Nottingham 2003-08-23 22:13:49 EDT
slocate does run at 'some early morning hour'. If you don't want it run except
for then, don't install anacron. (It's what runs it if the machine isn't up then.)

find on the root directory would be prohibitively slow. I don't think making
that the default is really workable.
Comment 9 Julien Olivier 2003-08-24 15:30:17 EDT
Well, why not using find for user-land searches and locate for root searches ? I
mean most of the times people just search for files they have recently created
or downloaded but don't remember where they put them. That means two things:
 1) The file is probably too recent to be in the locate database.
 2) The file is probably somewhere in the user's home.
So for most users, using find should be enough, and even better than locate.
Comment 10 Michael Lee Yohe 2003-08-25 11:40:15 EDT
I use locate for a variety of things - including reporting any new files that
were added since the last update.  For developers, it's invaluable to have -
since it's fast - to find header files or none-such in the bowels of your system.

I'm not sure your argument.  But for laptop users - a simple removal of a
cron.daily file removing the package altogether would fix the problem.
Comment 11 Julien Olivier 2004-04-11 08:20:59 EDT
I think a smart solution to this problem could be to disable anacron
(or remove updatedb from cron) on laptop installs (of course, that
would mean adding a laptop install to anaconda), and set
disable_quick_search to TRUE in gconf for the gnome-search-tool app.
And for people who really want to use locate, they could still run
updatedb manually or re-enable anacron.
Comment 12 Thomas Woerner 2004-10-15 14:38:13 EDT
Please file bugzilla entreis for these components, then.

Closing "NOT A BUG".

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