Red Hat Bugzilla – Bug 102722
Updatedb slows my laptop down
Last modified: 2007-04-18 12:57:00 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):
Steps to Reproduce:
Actual Results: You can't work anymore for about 5 minutes
Expected Results: Go on working :)
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.
Without putting lots of 'sleep()' calls in the code itself, the way it thrashes
the disk is not really fixable.
Excuse me if I'm being very naive there but... why not put lots of [optional]
sleeps in the code then ?
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
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.
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
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 ?
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
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 ?
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.
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.
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.
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.
Please file bugzilla entreis for these components, then.
Closing "NOT A BUG".