GNOME Bugzilla – Bug 579888
multiload-applet + sshfs breaks suspend
Last modified: 2020-11-06 19:55:39 UTC
Please describe the problem: Hello! I'm running Ubuntu Jaunty on two machines, one x86, the other amd64. The following bug happens on both: Whenever I have the multiload-applet active, with the “harddisk” view enabled, _and_ I have something mounted with SSHFS, suspend doesn't work anymore. Steps to reproduce: 1) Add a "System Monitor" applet on your panel. (The applet's binary is /usr/lib/gnome-applets/multiload-applet-2.) 2) Set the applet to display disk load (right click -> Preferences... -> check "Harddisk"). 3) Mount something via sshfs. 4) Open the mount point in Nautilus. (I'm not sure that's actually necessary, I just tested it now and it worked without this step; just do it to be sure.) 5) Try to suspend the computer. (Either via the “user switcher” applet or a hotkey.) Actual results: On both my computers the above sequence starts a suspend. The screen turns black (I think there's a cursor there, not sure if all the time) for about 20 seconds. Then there's a message to the effect "timeout passed, task refused to freeze: multiload-apple". (No idea why the name is truncated.) Then the suspend is abandoned (i.e., the session resumes and I get the unlock screen dialog). Expected results: Just a normal, working suspend... Does this happen every time? Every time I try it, since at the very least January. (I've been having this problem for at least a year, but only this January I noticed the connection with the multiload applet.) Other information: I'm not sure how long this bug has been active. My laptop has had this problem intermittently since before Intrepid (~ twelve months ago) but I never noticed the "timeout" message and I would just shut the machine down if it didn't suspend in a few seconds, assuming it was frozen. My other computer didn't have the "load" applet enabled (until I added it for testing), so this never manifested there. I've tried reproducing this on my work machine (Intrepid) but apparently it has other bugs that interfere (i.e., sometimes it just doesn't resume, regardless of the steps above). To mount via SSHFS I have lines like: sshfs#bogdanb@tanelorn.lan:/mnt/corum /media/corum fuse noauto,rw,noatime,user,nonempty 0 0 sshfs#bogdanb@tanelorn.lan:/mnt/elric /media/elric fuse noauto,rw,noatime,user,nonempty 0 0 sshfs#bogdanb@tanelorn.lan:/ /media/tanelorn fuse noauto,rw,noatime,user,nonempty 0 0 in /etc/fstab. "tanelorn.lan" is my server. I mount them with a simple "mount /media/corum". This is the only kind of remote directory that I have available, so I don't know if it happens with other types of shares. This happens both via Ethernet and WiFi, on two different machines.
It appears that we get the disk load from libgtop. We only call it intermittently, but it appears to have a "server" that persistently tracks things. This may be causing a bad interaction with sshfs. Thats the current theory anyway, I'm still investigating.
I suspect fixing this may be as simple as adding: || strcmp(mountentries[i].type, "fuse.sshfs") == 0 to the if block in gnome-applet's multiload/linux-proc.c:GetDiskLoad().
Created attachment 166999 [details] [review] patch to multiload to skip polling sshfs filesytems This is a patch for the suggestion from kijiki0@netscape.net. It has solved the bug for me in all my testing thus far.
I assume this is the same core problem: if an sshfs mount's remote machine becomes unavailable, the system monitor applet will freeze and remain in uninterruptible sleep forever.
This also affects Gnome on Debian Squeeze (gnome-applets 2.30.0-3). What is required to move this bug from status UNCONFIRMED so that this problem can be resolved in a future release of gnome?
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-applets/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.