Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 112964 - slocate.cron and updatedb.conf duplicate info
slocate.cron and updatedb.conf duplicate info
Product: Fedora
Classification: Fedora
Component: slocate (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2004-01-06 14:35 EST by Doncho N. Gunchev
Modified: 2014-03-16 22:41 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-03-29 09:14:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Doncho N. Gunchev 2004-01-06 14:35:25 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Gecko/20031015 Firebird/0.7

Description of problem:
In slocate.cron we have
--- cut ---
/usr/bin/updatedb -f "nfs,smbfs,ncpfs,proc,devpts,none" -e
--- cut ---
while in updatedb.conf:
--- cut ---
PRUNEFS="devpts NFS nfs afs sfs proc smbfs autofs auto iso9660 none"
PRUNEPATHS="/tmp /usr/tmp /var/tmp /afs /net /sfs"
export PRUNEFS
--- cut ---
The problem is that someone (like me) can update /etc/updatedb.conf
and think he did something, but cron does not care at all what's
inside. in my system I changed the cron job to:
--- cut ---
renice +19 -p $$ >/dev/null 2>&1
#/usr/bin/updatedb -f "nfs,smbfs,ncpfs,proc,devpts,none" -e
. /etc/updatedb.conf
--- cut ---
and it seems to work fine for me. The question is why have 2 places to
specify which file systems and which directories should not be indexed
by slocate?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. edit /etc/updatedb.conf
2. wait 1 day / run /etc/cron.daily/slocate.cron by hand
3. use locate to see what was indexed

Actual Results:  changing /etc/updatedb.conf does not affect anything,
and I don't like editing cron jobs or /etc/rc.d/init.d scripts

Expected Results:  there should be one place to correct slocate behaviour

Additional info:

It seems to be this way from long time (RedHat 6.2 or even earlier)
Comment 1 Karsten Hopp 2004-03-29 09:14:01 EST
fixed in slocate-2.7-8 

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