Red Hat Bugzilla – Bug 68304
RFE: Disable daily execution of "/etc/cron.daily/slocate.cron"
Last modified: 2014-03-16 22:28:39 EDT
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): How reproducible: Always 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. 3. 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. Additional info:
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 during installation).
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.
Hmm ... 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: - /etc/cron.daily/makewhatis.cron - /etc/cron.daily/rpm - /etc/cron.weekly/makewhatis.cron 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. :-)
fix verified closing -> RAWHIDE.