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 Epiphany/0.8.2 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: Always Steps to Reproduce: 1.Work 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.
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 computer.
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 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 ?
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".