Bug 102722

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".