Mounted sshfs filesystems sometimes prevent suspend

[Robie Basak]

Using Ubuntu artful with linux-image-4.10.0-26-generic 4.10.0-26.30 and sshfs 2.8-1. I use "sshfs -o reconnect" and often run gvim against a file on an sshfs filesystem.

Sometimes when I suspend I get:

Jul 4 20:59:08 xps kernel: [46684.608740] PM: Syncing filesystems ... done.
Jul 4 20:59:08 xps kernel: [46684.613278] PM: Preparing system for sleep (mem)
Jul 4 20:59:08 xps kernel: [46684.613788] Freezing user space processes ...
Jul 4 20:59:08 xps kernel: [46704.620140] Freezing of tasks failed after 20.006 seconds (1 tasks refusing to freeze, wq_busy=0):
Jul 4 20:59:08 xps kernel: [46704.620534] gvim D 0 11155 1336 0x00000004
Jul 4 20:59:08 xps kernel: [46704.620541] Call Trace:
Jul 4 20:59:08 xps kernel: [46704.620556] __schedule+0x233/0x6f0
...
Jul 4 20:59:08 xps kernel: [46704.620679] entry_SYSCALL_64_fastpath+0x1e/0xad
...
Jul 4 20:59:08 xps kernel: [46704.620711] Restarting tasks ... done.

...and the system fails to suspend.

AFAICT, this is https://bugzilla.redhat.com/show_bug.cgi?id=656992 and https://lists.debian.org/debian-kernel/2011/10/msg00412.html has an extensive explanation. The corresponding Debian bug was closed long ago due to inactivity. It isn't exactly bug 388419 though since that is about behaviour after resume, rather than failure to suspend.

This affects sshfs-fuse, but it sounds like a full fix would be in the kernel. I wonder if it's possible to work around in userspace packaging in sshfs-fuse, though, by arranging some action in userspace before suspend?

It seems unlikely that this will be addressed any time soon, but it'd be nice to keep a bug open in Launchpad so that users can have a single rallying point.
---
ApportVersion: 2.20.5-0ubuntu5
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: robie 1519 F.... pulseaudio
CurrentDesktop: GNOME
DistroRelease: Ubuntu 17.10
HibernationDevice: RESUME=UUID=ae23a431-2f44-4c12-992a-a0da8186bfcc
InstallationDate: Installed on 2017-05-11 (54 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170507)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 0bda:568b Realtek Semiconductor Corp.
 Bus 001 Device 002: ID 0cf3:e300 Atheros Communications, Inc.
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: Dell Inc. XPS 13 9360
Package: sshfs-fuse
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.10.0-26-generic.efi.signed root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 4.10.0-26.30-generic 4.10.17
RelatedPackageVersions:
 linux-restricted-modules-4.10.0-26-generic N/A
 linux-backports-modules-4.10.0-26-generic N/A
 linux-firmware 1.167
Tags: artful
Uname: Linux 4.10.0-26-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip libvirt lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 01/18/2017
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.3.2
dmi.board.name: 00GCYR
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr1.3.2:bd01/18/2017:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn00GCYR:rvrA00:cvnDellInc.:ct9:cvr:
dmi.product.name: XPS 13 9360
dmi.sys.vendor: Dell Inc.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1702368

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Robie Basak (racb)]

apport information

[Robie Basak (racb)]

apport information

[Robie Basak (racb)]

apport information

[Robie Basak (racb)]

apport information

[Robie Basak (racb)]

apport information

[Robie Basak (racb)]

apport information

[Robie Basak (racb)]

apport information

[Robie Basak (racb)]

apport information

[Robie Basak (racb)]

apport information

[Robie Basak (racb)]

apport information

[Robie Basak (racb)]

apport information

[Robie Basak (racb)]

apport information

[Robie Basak (racb)]

apport information

[Robie Basak (racb)]

apport information

[Robie Basak (racb)]

apport information

[Robie Basak (racb)]

I'm also hitting this with:

Jul 6 08:19:25 xps kernel: [93020.924360] gsd-housekeepin D 0 1729 1350 0

Creating a task against gnome-settings-daemon in case a workaround is possible.

[Robie Basak (racb)]

A workaround for my gvim-based hang is to not have gvim open on the sshfs when I suspend. I don't have that option with gsd-housekeeping, so I basically have to unmount sshfs before suspend, which breaks everything else (eg. open bash prompts). Using "sshfs -o reconnect" works fine except for this.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Horst Schirmeier (horst)]

I'm consistently seeing this on Zesty (linux-image-4.10.0-33-generic), the same fuse mount didn't prevent suspending before Ubuntu 17.04:

[262730.781448] Freezing of tasks failed after 20.009 seconds (1 tasks refusing to freeze, wq_busy=0):
[262730.781679] FileInfoThread D 0 10555 1869 0x00000104
[262730.781684] Call Trace:
[262730.781695] __schedule+0x233/0x6f0
[262730.781699] schedule+0x36/0x80
[262730.781705] request_wait_answer+0x14b/0x210
[262730.781711] ? wake_atomic_t_function+0x60/0x60
[262730.781716] __fuse_request_send+0x84/0x90
[...]

[Ian Graham (fender1988)]

If it's any bit of helpful information, I occasionally have this issue (on 18.04) and it is fixed by a proper shutdown and boot. It seems to happen for me when one of the servers that I sshfs to crashes/becomes unavailable (or something else server side) and the issue persists past the time in which the server is back and functional.

[Konstantin (hi-angel-z)]

This issue seems to have been fixed as of 5.8.3 kernel.

I recently reported this upstream https://bugzilla.kernel.org/show_bug.cgi?id=208841 and after I was asked to re-test with the newer kernel, it turned out the problem no longer reproducible. I figured I should search if there were other reports of this problem, so here I am: if you upgrade to at least 5.8.3, the problem is absent.