Bug 604145

Summary:	updatedb.conf should prune fuse.sshfs file systems
Product:	[Fedora] Fedora	Reporter:	long
Component:	mlocate	Assignee:	Miloslav Trmač <mitr>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	13	CC:	bugzilla.redhat.com, mitr
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	mlocate-0.24-1.fc15	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-04-05 21:35:48 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 long 2010-06-15 14:03:31 UTC

Description of problem:
updatedb.conf should have fuse.sshfs in PRUNEFS list.  Otherwise it tries to traverse sshfs mounts.  

Version-Release number of selected component (if applicable):
mlocate-0.22.4-1.fc13.x86_64

How reproducible:
always

Steps to Reproduce:
1. mount a bunch of remote directories using sshfs
2. wait for updatedb to run
3.
  
Actual results:
updatedb is still running a day later

Expected results:
updatedb completes

Additional info:

Comment 1 Miloslav Trmač 2010-06-21 15:03:54 UTC

Thanks for your report.

The sshfs file system does not appear in /proc/filesystems, so it is not automatically detected:

/proc/mounts:
> user@host: /home/mitr/s fuse.sshfs rw,nosuid,nodev,relatime,user_id=500,group_id=500,max_read=65536 0 0

grep fuse /proc/filesystems:
> nodev	fuse
> 	fuseblk
> nodev	fusectl

Comment 2 Penelope Fudd 2010-06-25 16:39:55 UTC

This is identical to my bug 608094; I should have seen this bug first.

After thinking about it, I'd rather see better behaviour from sshfs than special-case behaviour added to updatedb, if only because all programs that walk the filesystem should be modified the same way, or else they'll hang at the same point.  

Can you visualize modifying 'ls -R' and 'find' to work around hanging sshfs filesystems?

Comment 3 Fedora Update System 2011-03-31 19:18:39 UTC

mlocate-0.24-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/mlocate-0.24-1.fc15

Comment 4 Miloslav Trmač 2011-03-31 19:21:46 UTC

Thanks for your report.  mlocate should ideally exclude all fuse file systems; fuse.sshfs is one of those that really matters, so I have added an explicit exclusion in mlocate-0.24-1.

Comment 5 Fedora Update System 2011-04-02 02:48:32 UTC

Package mlocate-0.24-1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mlocate-0.24-1.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/mlocate-0.24-1.fc15
then log in and leave karma (feedback).

Comment 6 Penelope Fudd 2011-04-02 07:49:50 UTC

Does that mean that there won't be a general fix for sshfs (or fuse), so that 'ls' and 'find' will still have this problem?

Comment 7 Miloslav Trmač 2011-04-04 15:00:40 UTC

mlocate needs to exclude sshfs in any case - there is usually very little point in enumerating a remote filesystem (which can potentially be several terabytes large) over ssh (potentially using a slow link).  updatedb taking several days can happen in such situations even if nothing is "wrong".

If sshfs unexpectedly hangs for you, that's something different.  Looking at bug #505937 and bug #615822, sshfs hangs are being addressed over time, but I don't know if the particular problems you have been seeing is fixed.  I'd suggest filing a separate report against the "fuse-sshfs" component, with detailed instructions for how to reproduce the situation.

Comment 8 Fedora Update System 2011-04-05 21:35:33 UTC

mlocate-0.24-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.