From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012
Description of problem:
The default cron job for the slocate package (/etc/cron.daily/slocate.cron)
calls "locate" using the updatedb symlink.
When this runs on a machine with ext3 filesystems the resulting slocate.db
(/var/lib/slocate/slocate.db) is about 1byte in size. It seems to only
contain the ascii digit "1".
In the man page for updatedb it is stated that locate simply runs with the
-u option when called as updatedb.
There's clearly more going on here, since the following change to
/etc/cron.daily/slocate.cron seems to fix the problem:
[ Original line ]
/usr/bin/updatedb -f "nfs,smbfs,ncpfs,proc,devpts" -e
[ Modified line ]
/usr/bin/locate -u -f "nfs,smbfs,ncpfs,proc,devpts" -e
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Upgrade to RH 7.2
2.Run the default slocate.cron in /etc/cron.daily
3.Find that /var/lib/slocate/slocate.db is now a nearly empty file
Actual Results: My slocate.db file becomes a 1 byte file containing the
Expected Results: My slocated.db should have been updated to contain a
nice big index of my filesystems.
This happens on a Red Hat 7.1 box that has been retrofitted with ext3
filesystems as well.
This works fine for me on ext3; I get a normal sized file.
What happens if you strace the call to slocate?
Also, do you have your filesystem set to 'auto' in /etc/fstab?
This happens to me in RedHat 7.2 as well, if the root file system is auto. I
edited /etc/mtab by hand and changed 'auto' to 'ext3' and re-ran
/etc/cron.daily/slocate.cron and it worked fine. BTW, even though I have 'auto'
in /etc/fstab for all of my ext3 file systems, only the / filesystem showed up
as auto in /etc/mtab.
Please verify this with a newer version of Red Hat Enterprise Linux or
Fedora Core and reopen it against the new version if it still occurs.
Closing as "not a bug" for now.