Bug 68304 - RFE: Disable daily execution of "/etc/cron.daily/slocate.cron"
Summary: RFE: Disable daily execution of "/etc/cron.daily/slocate.cron"
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: slocate (Show other bugs)
(Show other bugs)
Version: null
Hardware: i386 Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2002-07-08 22:53 UTC by Peter van Egdom
Modified: 2014-03-17 02:28 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-08-28 10:38:26 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Peter van Egdom 2002-07-08 22:53:06 UTC
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:

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.

Additional info:

Comment 1 Nathan G. Grennan 2002-07-08 23:54:59 UTC
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.

Comment 2 Miloslav Trmac 2002-07-09 02:20:16 UTC
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).

Comment 3 petrosyan 2002-07-09 03:25:13 UTC
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.

Comment 4 Jens Petersen 2002-08-05 06:38:35 UTC
How about a compromise: running it weekly rather than daily.

Comment 5 Peter van Egdom 2002-08-05 17:42:00 UTC
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?

Comment 6 Marc Deslauriers 2002-08-25 15:11:01 UTC
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...

Comment 7 Jens Petersen 2002-08-28 10:38:19 UTC
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. :-)

Comment 8 Ben Levenson 2002-09-05 21:47:08 UTC
fix verified
closing -> RAWHIDE.

Note You need to log in before you can comment on or make changes to this bug.