multiload-applet + sshfs breaks suspend

[Bogdan Butnaru]

Binary package hint: gnome-applets

Hello! I'm running up-to-date Jaunty on two machines, one x86, the other amd64. The following bug happens on both.

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. (As far as I can tell, you need to have files open on it. Only a 'ls' is not enough, but playing a song or something like that causes the same bug.)
5) Try to suspend the computer. (Either via the "user switcher" applet or a hotkey.)

Problem: 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).

I've done a bit of testing this morning and as far as I can tell removing any of the steps above prevents this from happening (i.e., suspend works).

I'm not sure how long this bug has been active. My laptop has had this problem intermittently since before Intrepid, but I never noticed the "timeout" message and I would just shut it down if it didn't suspend in a few seconds. My other computer didn't have the "load" applet enabled (until I added it for testing), so this never manifested. 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).

Package: gnome-applets
Version: 2.25.2-0ubuntu1

Package: sshfs
Version: 2.1-1

(laptop:)
$ uname -a
Linux arioch 2.6.28-4-generic #11-Ubuntu SMP Fri Jan 16 21:57:57 UTC 2009 i686 GNU/Linux
(desktop:)
$ uname -a
Linux mabelode 2.6.28-4-generic #11-Ubuntu SMP Fri Jan 16 21:50:52 UTC 2009 x86_64 GNU/Linux

[Sebastien Bacher (seb128)]

thank you for your bug report, how do you use sshfs to do some mounting? is that specific to this one?

[Bogdan Butnaru (bogdanb)]

Hi Sebastian!

To mount via SSHFS I have lines like:

sshfs#<email address hidden>:/mnt/corum /media/corum fuse noauto,rw,noatime,user,nonempty 0 0
sshfs#<email address hidden>:/mnt/elric /media/elric fuse noauto,rw,noatime,user,nonempty 0 0
sshfs#<email address hidden>:/ /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. It's also the only FUSE filesystem I mount myself, although there are a couple others I don't know about:

bogdanb@mabelode:~$ mount|grep fuse
fusectl on /sys/fs/fuse/connections type fusectl (rw)
gvfs-fuse-daemon on /home/bogdanb/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=bogdanb)
<email address hidden>:/mnt/corum on /media/corum type fuse.sshfs (rw,noexec,nosuid,nodev,noatime,max_read=65536,user=bogdanb)
<email address hidden>:/mnt/elric on /media/elric type fuse.sshfs (rw,noexec,nosuid,nodev,noatime,max_read=65536,user=bogdanb)

This happens both via Ethernet and WiFi, on two different machines, like I said.

I'm not sure if it's relevant, but _unmounting_ doesn't go as usual: I either have to do a "sudo umount" or a "fusermount -u" for FUSE mounts, I'm not sure why.

[LKaestner (lkaestner)]

Hi Sebastian and Bogdan,
I experience this nerving bug too under Ubuntu 8.10 and 9.04a on PC and Laptop.
It persists with version 2.2 of sshfs, too.
Hopefully the bug will be fixed in the final release of Jaunty.

[Sebastien Bacher (seb128)]

somebody having the issue should send the bug to bugzilla.gnome.org where the people writting the code will read it, it will not likely be fixed for jaunty otherwise

[Sebastien Bacher (seb128)]

is that still an issue now in jaunty? did you send the bug to GNOME?

[Bogdan Butnaru (bogdanb)]

Hi Sebastien. Yes, it's still happening now. (I stopped using that applet since I found it was the culprit; I enabled it just now to check.)

Bugzilla tends to get on my nerves, but I'll try to enter a report now.

[Sebastien Bacher (seb128)]

thank you for sending the bug to GNOME

[Nikil Mehta (nikil.mehta)]

Wow, I am amazed you tracked this down. I've been seeing this bug for the last week since I've been using sshfs and it's been driving me crazy. Thanks so much for outlining the steps to reproduce. I can now avoid by removing the gnome system monitor applet :)

Hopefully this will get fixed upstream.

[Chris (bridgeriver)]

I've been seeing this bug for years now, but had never realized it was connected to the multiload applet. I just recently discovered that one machine was able to suspend successfully with an sshfs mount active. Guess what? It's my one machine that doesn't have multiload running.

[Sebastian Thürrschmidt (thuerrschmidt)]

The bug remains unfixed in Karmic with Gnome 2.29.1. I stumbled on this bug report (excellent work from Bogdan, btw) after I had, for the umpteenth time, lost suspend on my MacBook 4,1 with Ubuntu. It is indeed the combination of the disk load monitor with an active sshfs mount that blocks the multiload-applet task and causes any suspend attempt to fail. It wasn't easy to figure this out, with truncated "multiload-apple" [sic] strings in my log files being one of the major hurdles.

Bogdan, would you please go the trouble of reporting this on Gnome's bugzilla? We really need to take the detective work out of a functioning suspend/hibernate. Thank you very much!

[Bogdan Butnaru (bogdanb)]

Hi Sebastian, it's been already reported at https://bugzilla.gnome.org/show_bug.cgi?id=579888

[LKaestner (lkaestner)]

The bug remains unfixed in Ubuntu 10.04 (Lucid Lynx) with:
 * gnome-applets 2.30.0-0ubuntu2
 * sshfs 2.2-1build1
 * linux-generic 2.6.32-22-generic x86_64

[Alex Munroe (x-launchpad-veekun-com)]

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.

[Daniel Johansson (danjo133)]

Relevant for 10.10 as well, unclear if the last two comments to the gnome-bugzilla mentioned earlier pertains to a fix that's in the gnome-applets codebase or if it was independent testing, I hope it will be fixed in time for 11.04.

[Fingel (unholysponger)]

I can confirm this bug, drove me crazy until I found the real cause was the multiload applet.
This is dangerous because it can cause some laptops to overheat when the user believes it is suspended.

[Ryan T Long (rtlong)]

This is a strange bug and it makes me sad. I love having that scrolling graph of my system vitals.

[Sridhar (sridhar-redhat-bugs)]

Description of problem:

The "Harddisk" monitor in the GNOME System Monitor applet doesn't let the computer suspend if an active sshfs session is open.

Version-Release number of selected component (if applicable):

gnome-applets-2.3.2.0-3.fc14.x86_64

How reproducible:

Always

Steps to Reproduce:

1) Add a "System Monitor" applet on your panel. (The applet's binary is /usr/libexec/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. (As far as I can tell, you need to have files open on it. Only a 'ls' is not enough, but playing a song or something like that causes the same bug.)
5) Try to suspend the computer. (Either via the "user switcher" applet or a hotkey.)

Additional info:

I used the description from https://bugs.launchpad.net/ubuntu/+source/gnome-applets/+bug/319575 almost verbatim, as this appears to be the exact same bug.

[Jayen (jayen)]

Having the same bug, but I rarely use nautilus or play music, so I'm not sure what the trigger is for step 4 in my case. The last time it happened, I think I used nano+suspend+suspend, so maybe the suspend breaks sshfs in my case, since my internet connection dies when I suspend, but sshfs is still running when I wake up. My workaround is to kill sshfs before suspending.

[Jayen (jayen)]

nvm, I just managed to reproduce this bug on maverick without a step 4. Just sshfs stopped multiload-applet from allowing suspend. Full command: sshfs -o gid=`id -g` -o idmap=user -o "ControlPath=/tmp/sshfs.cse" cse: ~/cse　-o PreferredAuthentications=password -o reconnect

And in my ssh_config:
ControlMaster auto
ControlPath ~/.ssh/control_%l_%h_%p_%r
HashKnownHosts no
ForwardX11 yes
StrictHostKeyChecking no
CheckHostIP no
NoHostAuthenticationForLocalhost no
ServerAliveCountMax 3
ServerAliveInterval 20
Host cse
 HostName login.cse.unsw.edu.au

[Fedora (fedora-redhat-bugs)]

This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 14 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[mvaldez (mario-mariovaldez)]

This bug still exists in Precise (12.04). The only workaround for end-users is to disable the disk monitoring (Preferences, uncheck Disk).

There is a patch available at https://bugzilla.gnome.org/show_bug.cgi?id=579888#c3 (the upstream bug, still open BTW) but it is not included with the latest (gnome-applets-3.5.2) release nor the Trusty version (3.5.92). The only thing that patch does is to exclude the SSHFS mounts from monitoring (along with CIFS/Samba and NFS mounts which are currently excluded).