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)
fixed in slocate-2.7-8