Bug 112964 - slocate.cron and updatedb.conf duplicate info
Summary: slocate.cron and updatedb.conf duplicate info
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: slocate (Show other bugs)
(Show other bugs)
Version: 1
Hardware: All Linux
medium
low
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-01-06 19:35 UTC by Doncho Gunchev
Modified: 2014-03-17 02:41 UTC (History)
3 users (show)

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: ---


Attachments (Terms of Use)

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 


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