Fedora Account System
Red Hat Associate
Red Hat Customer
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",
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.
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
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.
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.
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.
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
This problem has bee fixed upstream but the patch is too invasive to be ported back to Fedora 12. Closing