Bug 112964

Summary: slocate.cron and updatedb.conf duplicate info
Product: [Fedora] Fedora Reporter: Doncho Gunchev <dgunchev>
Component: slocateAssignee: Bill Nottingham <notting>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: low Docs Contact:
Priority: medium    
Version: 1CC: dgunchev, mitr, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-03-29 14:14:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Doncho Gunchev 2004-01-06 19:35:25 UTC
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
"/tmp,/var/tmp,/usr/tmp,/afs,/net"
--- 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
export PRUNEPATHS
--- 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 ---
#!/bin/sh
renice +19 -p $$ >/dev/null 2>&1
#/usr/bin/updatedb -f "nfs,smbfs,ncpfs,proc,devpts,none" -e
"/tmp,/var/tmp,/usr/tmp,/afs,/net"
. /etc/updatedb.conf
/usr/bin/updatedb
--- 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):
slocate-2.6-8

How reproducible:
Always

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 14:14:01 UTC
fixed in slocate-2.7-8