Bug 505937 - If some sshfs mount times out, any yum install operation will hang at "Running Transaction Test"
If some sshfs mount times out, any yum install operation will hang at "Runnin...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: fuse-sshfs (Show other bugs)
12
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Peter Lemenkov
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-14 16:20 EDT by Rene Ploetz
Modified: 2014-01-21 18:09 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-02-03 10:59:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rene Ploetz 2009-06-14 16:20:18 EDT
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@192.168.1.1:/ /mnt/router fuse port=222,users,allow_other,reconnect,transform_symlinks,BatchMode=yes  0 0
sshfs#root@192.168.1.1:/mnt/backup /mnt/backup1 fuse port=222,users,allow_other,reconnect,transform_symlinks,BatchMode=yes  0 0
sshfs#root@192.168.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 02:25:35 EDT
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 13:17:50 EDT
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 07:20:10 EDT
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 04:46:12 EDT
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 08:18:22 EDT
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 05:11:52 EST
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 10:59:20 EST
This problem has bee fixed upstream but the patch is too invasive to be ported back to Fedora 12. Closing

Note You need to log in before you can comment on or make changes to this bug.