locate's updatedb command will fail without displaying any indication of its failure when it reaches a mounted but no longer physically available samba share. Fix: I'd supply a patch if I had any coding ability, so unfortunately, this PR is as far as I can help. How-To-Repeat: First, run updatedb via either the 310.locate script or locate.updatedb. Check the size of this file, and maybe even make a diff for later comparison (locate "" > diff1) On the FreeBSD system, mount a samba share from another Windows PC on the LAN. Turn the Windows PC off without unmounting the share on the FreeBSD system. Run updatedb again with eitehr 310.locate or locate.updatedb. It will finish wihout showing any error. Now any file that would be checked by updatedb after /mnt is not found by "locate". (try a new diff: locate "" > diff2) Compare the diffs, and notice that the second one stops at /mnt
This bug is still around. I'm not sure, if I should open a new bug-report or add to this bug-report ? Had a hard time to track it down on a FreeBSD 11, with a generic kernel. However running it the "right way" it does nothing, except a empty locate-database: --- # time sh /etc/periodic/weekly/310.locate Rebuilding locate database: 0.159u 0.341s 0:00.74 66.2% 77+206k 38+0io 0pf+0w --- Running /usr/libexec/locate.updatedb as root "works", except that it is not recommended. My work-around was to use PRUNEPATHS in /etc/locate.rc, and add '/mnt'. Then /etc/periodic/weekly/310.locate runs as expected.
I don't think that it is the job of locate to complain about stale mount points. But if it fails, it should display a reason why. IMHO the locate database should contain only local files, and not any network mounted disks as NFS or samba.
(all just my personal opinion/thoughts) I agree, that it is not locate(.updatedb)'s task to find stale/broken mount-points. But I do think it should make a shout, telling what went wrong, and perhaps then skip that mount-point, and continue with the next in its list. On the subject "only local files".. From 'man locate': ".. The database is recomputed periodically (usually weekly or daily), and contains the pathnames of all files which are publicly accessible. .." 'all files which are public accessible'. From the man-page I would expect files in /mnt to be included, if public accessible. On the other hand /mnt is intended for temporary mount's. And as such, you can not expect the mounted file-system to be available at all time, specifically for a week (the interval updatedb is run at). Personally I vote for just skipping /mnt in the updatedb job (as in my workaround), but I do think it will somehow break with the man-page, or what one would/could expect after reading the man-page. BTW, as I read locate.rc, it does not index networked mounts, and on my system locate.updatedb fails, as original described, and I have not changed 'FILESYSTEMS' in my locate.rc: -cut- # # /etc/locate.rc - command script for updatedb(8) # # $FreeBSD: releng/11.0/usr.bin/locate/locate/locate.rc 290742 2015-11-13 06:16: 12Z des $ # # All commented values are the defaults ... # filesystems allowed. Beware: a non-listed filesystem will be pruned # and if the SEARCHPATHS starts in such a filesystem locate will build # an empty database. # # the default list contains all local file systems that are not synthetic, # loopback mounts, or read-only, according to lsvfs. # # be careful if you add 'nfs' or other network file system types or file # systems that generally reside on slow or removable devices like cd9660 #FILESYSTEMS="ufs ext2fs zfs xfs" -cut- In other words, on my system locate.updatedb fails hard-and-silenton a stale smb-mount, although it is set up to not index files on smb filesystems. Thank you for your time, Thomas
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
I have just tested on my system. The bug still persist on my "11.1-RELEASE-p9", as described in "Comment 1". With a stale smb-mount, I end up with an empty locate-database, after running '/etc/periodic/weekly/310.locate'. There is no warning-messages or error-messages.
Reset the assignee. Maybe someone else has an idea how to fix this.