From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020625
Description of problem:
(puts on anti-flame thrower suite, because I'm probably going
to walk on sacred ground here ... :-) )
Is it really necessary to execute this script which indexes
almost all files on the system? I ask this question because
in my experience a lot of Linux novice users complain about
the slow startup speed of either KDE or GNOME.
On a average system, the execution of the "slocate.cron"
script generates A LOT of disk I/O.
The only situation "slocate.cron" behaves nicely is on
those systems which are running 24/7 and when the
script runs at night.
But with the popularisation of Linux as a desktop
platform I have some doubts running this heavy
disk I/O beast each time the user turns on his PC.
(when I do a "time ./slocate.cron" on my Pentium/233
with about 2 gigabyte of Linux software this takes
about 5 minutes).
(when I do a "time ./slocate.cron" on my PIII/733
this still takes up to 1.5 minute)
These minutes are deadly with the extra disk I/O
generated by a starting KDE or GNOME environment
and could contribute to a less than stellar desktop
experience of Linux.
Personally, I just do a "chmod -x slocate.cron" to turn
off the script in "/etc/cron.daily".
Another point perhaps :
The users who need this functionality ("locate <somefile>")
most are the command line users; who know the command
"updatedb" and thus know the implications and what's
happening underneath the hood.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Turn on a 'slow PC' (e.g. a PII/233/96MB RAM) with
Red Hat Linux.
2. Hear the poor IDE harddisk rattle under the heavy torture
technique of the slocate.cron script while loading KDE.
Actual Results: I decided to to an RFE/RFC at the Bugzilla system of Red Hat.
(hey, one can alway try...) :-)
Expected Results: Turning off slocate.cron decreases startup time on the lower-
to mid range desktop PC's.
As far as I know slocate.cron isn't run after each boot. I looked and couldn't
find any trace of it in any of the files under /etc/rc.d It also isn't run at
the start of GNOME or KDE as far as I know. It is defined in crontab that all
the scripts in /etc/cron.daily are run at 4:02am. So if you happen to be awake
at 4:02am, or happen to be at 4:02am UTC(if you have the machine set to use UTC)
then you will be affected. Now I think about it, what you might have seen was
that the system was running slocate.cron on startup because it detected that it
had missed running it the night before. RedHat is configured with priority given
in preferences that it is a 24x7 server, since that is where most of RedHat's
business is. I doubt they want to change the default. It would also be pointless
to create a program to remove the execute bit on slocate.cron for you, when you
realize you can already do that. The only thing out of this bug report that
makes sense is that you might not want crond to play catch up on boot if it
senses it missed cron jobs.
See package anacron, it is configured to run "missed" /etc/cron.daily scripts 5
minutes after bootup.
The right solution is to simply
rpm -ev slocate
removing the background noise together with the functionality.
NOTE however that this might break some file finding utilities, which are just
front-ends to find and locate (I seem to recollect kfind is one, but it doesn't
contain the string 'locate' in the binary).
I'll leave the question of whether slocate should be by default included or not
to RH (I personally use it, but I don't mind having to choose it explicitly
I agree that it is very annoying to have updatedb being run every time 5 minutes
after the bootup.
I have 2 suggestions:
1. right now updatedb is being run with 0 nicety. Maybe running it with nicety
+16 or something like that would alleviate the pain.
2. how about disabling it alltogether ( or running it once every week ) on
laptop installation options. Laptops are not usually running 24/7, and they get
turned off a lot. So every time you turn on a laptop you have updatedb thrashing
your hardrive for a few minutes.
How about a compromise: running it weekly rather than daily.
Moving "slocate.cron" from "/etc/cron.daily/" to "/etc/cron.weekly/" seems
like a nice compromise to me.
Can we also, as suggested by hayastan132, run the 'time-consuming' scripts:
run with nice +19 ?
What do other people think about this?
My biggest complaint is the first reboot after a fresh install, anacron starts
slocate and everything slows down to a crawl. This is really annoying to the
first time user. Even setting slocate to "weekly" will have anacron starting
slocate after the first boot.
slocate should not get run by anacron, only by cron...
anacron-2.3-23 has the following changes:
* jobs are delayed for 65 minutes (previously 5 min)
* /etc/init.d/anacron runs anacron nice +19 and jobs are run serially
Hope this helps. :-)
closing -> RAWHIDE.