It is simple to reproduce:
1. mount something using sshfs
2. suspend machine

suspending will not work, and system will resume immieditly.

Ack, problems with sshfs vs. suspend are known.  There's no fix yet,
it's difficult to fix properly.  Workaround is to unmount sshfs
filesystems before suspend.

Thanks,
Miklos

A friend of mine and I just did some digging today and came up with more
knowledge on this problem.  The issue at hand appears to be that sshfs
isn't recognizing when the TCP/IP connection goes down.

I can, for instance, execute the following steps without problem:

1. Boot my machine fresh (no GUI login)
2. Mount something via sshfs
3. Suspend and resume an arbitrary number of times

However, the following reliably causes my machine to fail:

1. Boot my machine fresh (no GUI login)
2. Mount something via sshfs
3. Disconnect my network card or otherwise interfere with the sshfs
TCP/IP connection
4. Run a program which attempts to access the sshfs mount (which will
block indefinitely)
5. Attempt to suspend (which will fail)

Unmounting the filesystem will fail in this case because the program
started in step 4 is keeping the resource busy.  The FUSE kernel module
code which calls into the userspace daemon is performing a
non-interruptable I/O wait, so you can't signal it to die (even with
SIGKILL).  The only solution I've found is to kill -9 the sshfs
userspace daemon and then to fusermount -uz the mountpoint.  This
problem is still the case even when "-o ServerAliveInterval=15" is added
to the sshfs options; it appears at a glance that sshfs is not realizing
that its ssh client's connection has died even when it terminates due to
lack of keepalive packets.

This is a particularly frustrating problem when processes like dolphin
latch onto a directory in the sshfs mount and won't let go.
Specifically, I often suspend my laptop with sshfs processes running (as
in Lenny, this wasn't a problem for me).  When I start the laptop back
up and connect to a different network, everything is fine.  However, it
is at this point that the processes using the sshfs mount fail to escape
their blocking I/O calls, so it's when I decide to suspend at this
remote location that I am faced with the problem.

The following link appears to indicate that the sshfs people are aware
of the issue but have not yet prioritized it:
http://sourceforge.net/mailarchive/forum.php?thread_name=E1Nz5rE-0006Yj-EW%40pomaz-ex.szeredi.hu&forum_name=fuse-sshfs

For users who want this to be part of the behavior of things like the
GNOME power manager, I'd suggest editing /etc/hibernate/common.conf to
include something like

OnSuspend 20 killall -9 sshfs

Cheers,

Zach

So this issue is basically caused by bug #571005 - the processes
accessing a sshfs mount after the connection dies hang and thus cannot
be suspended.

Hi,

just one more data point: I'm pretty sure I'm seeing this also with
debian wheezy amd64 with gnome3 (sshfs 2.4-1). My laptop normally
hibernates when I close the lid but sometimes it keeps running really
hot in my backpack apparently because hibernate failed.

Would it be possible for debian to

1) warn the user with using some audio alert that the hibernate failed?

2) automatically kill sshfs processes on hibernate?

3) show a dialog like "hibernate failed, this might be caused by the
running sshfs process (pid ...). Would you like to kill sshfs processes
on hibernate automatically? You need to remount them manually on
resume."?