Bug 505937

Summary: If some sshfs mount times out, any yum install operation will hang at "Running Transaction Test"
Product: [Fedora] Fedora Reporter: Rene Ploetz <reneploetz>
Component: fuse-sshfsAssignee: Peter Lemenkov <lemenkov>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: ffesti, james.antill, jnovy, lemenkov, pmatilai, tim.lauridsen
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-02-03 15:59:20 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 Rene Ploetz 2009-06-14 20:20:18 UTC
Description of problem:
If some sshfs mount times out, any yum install operation will hang at "Running Transaction Test"

Version-Release number of selected component (if applicable):
rpm-4.7.0-1.fc11.x86_64
yum-3.2.22-4.fc11.noarch
fuse-sshfs-2.2-2.fc11.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. mount some directory via sshfs
2. wait for timeout
3. try to install a package via yum
  
Actual results:
yum hangs at "Running Transaction Test"

Expected results:
yum should perform the install

Additional info:

sshfs mount lines from /etc/fstab:
sshfs#root.1.1:/ /mnt/router fuse port=222,users,allow_other,reconnect,transform_symlinks,BatchMode=yes  0 0
sshfs#root.1.1:/mnt/backup /mnt/backup1 fuse port=222,users,allow_other,reconnect,transform_symlinks,BatchMode=yes  0 0
sshfs#root.1.1:/var/log/backup /mnt/backup2 fuse port=222,users,allow_other,reconnect,transform_symlinks,BatchMode=yes  0 0

last lines of 'strace yum install <packagename>'
open("/etc/mtab", O_RDONLY)             = 18
futex(0x3c10b6b020, FUTEX_WAKE_PRIVATE, 2147483647) = 0
fstat(18, {st_mode=S_IFREG|0644, st_size=742, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffa49a1e000
read(18, "/dev/mapper/vg_oetzi-lv_root / ex"..., 4096) = 742
stat("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
stat("/sys", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
stat("/dev/pts", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
stat("/boot", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
stat("/misc", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/dev/shm", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=200, ...}) = 0
stat("/proc/sys/fs/binfmt_misc", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
stat("/home/oetzi/.gvfs", 0x7fff51a2ddc0) = -1 EACCES (Permission denied)
stat("/mnt/router", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/mnt/backup1",

Comment 1 Panu Matilainen 2009-06-17 06:25:35 UTC
Hmm. For regular fuse mounts it gets handled by -EACCESS (see how /home/oetzi/.gvfs is handled in the strace log) but not so for root fuse mounts. Maybe rpm should just ignore any fuse mounts, it seems unlikely that fuse would be used for system directories. Or have a configurable blacklist of filesystem types to ignore.

Comment 2 Rene Ploetz 2009-06-17 17:17:50 UTC
The problem may be that all network file systems are affected.

Prior to reporting the bug, I found some references that this happens with NFS mounts as well: https://www.redhat.com/archives/fedora-list/2008-January/msg02241.html

Comment 3 Florian Festi 2009-09-10 11:20:10 UTC
Hmm, I really don't see how rpm could solve this problem on it's own. May be the connection is be restored later (unlikely for ssh but possible for NFS or other network protocols). Only the fuse driver can decide when and how to time out.

One solution would be to add the mount point into netsharedpath. Right now this does not help as RPM still accesses file systems listed in there. Please have a look at #495623 which is related to this issue.

The problem that access to sshfs blocks stat calls is completely unrelated to RPM though forwarding this bug fuse-sshfs. IMHO the call should time out and return with an error as e.g. -EACCESS.

Comment 4 Peter Lemenkov 2009-09-16 08:46:12 UTC
Actually, it's not an issue in FUSE - it's an issue in yum (or maybe rpm), which hangs if some network mounts died (even if these mounts have nothing with yum/rpm).

However, in case of broken ssh connection, there is no way to revive mount back, so I'll take a look at this particular case.

Comment 5 seth vidal 2009-09-16 12:18:22 UTC
When you're at the  Running Transaction Test and running transaction stages the process is all inside rpmlib and yes, rpm does get unhappy if mounts become unresponsive when it is trying to run or test a transaction.

Comment 6 Bug Zapper 2009-11-16 10:11:52 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 7 Florian Festi 2010-02-03 15:59:20 UTC
This problem has bee fixed upstream but the patch is too invasive to be ported back to Fedora 12. Closing