2

After unmounting a remote file system with fusermount -u ~/sshfs_mount/ and then calling systemctl suspend my Arch Linux 4.20.2 froze for about 20 seconds.

After those 20 seconds, the system became responsive again (it didn't suspend). Then I tried to suspend once more which succeeded this time.

Checking out journalctl, I found a lot of these messages:

Jan 21 10:10:45 me systemd-logind[510]: Power key pressed.
Jan 21 10:10:45 me kernel: PM: suspend exit
Jan 21 10:10:45 me kernel: PM: suspend entry (s2idle)
Jan 21 10:11:05 me kernel: PM: Syncing filesystems ... done.
Jan 21 10:11:05 me kernel: Freezing user space processes ... 
Jan 21 10:11:05 me kernel: Freezing of tasks failed after 20.002 seconds (15 tasks refusing to freeze, wq_busy=0):
Jan 21 10:11:05 me kernel: pool            D    0 10812   5584 0x00000084
Jan 21 10:11:05 me kernel: Call Trace:
Jan 21 10:11:05 me kernel:  ? __schedule+0x29b/0x8b0
Jan 21 10:11:05 me kernel:  ? __wake_up_common+0x77/0x140
Jan 21 10:11:05 me kernel:  ? preempt_count_add+0x79/0xb0
Jan 21 10:11:05 me kernel:  schedule+0x32/0x90
Jan 21 10:11:05 me kernel:  request_wait_answer+0xaa/0x1f0 [fuse]
Jan 21 10:11:05 me kernel:  ? wait_woken+0x80/0x80
Jan 21 10:11:05 me kernel:  __fuse_request_send+0x61/0x80 [fuse]
Jan 21 10:11:05 me kernel:  fuse_simple_request+0xcd/0x190 [fuse]
Jan 21 10:11:05 me kernel:  fuse_statfs+0xde/0x140 [fuse]
Jan 21 10:11:05 me kernel:  statfs_by_dentry+0x67/0x90
Jan 21 10:11:05 me kernel:  vfs_statfs+0x16/0xc0
Jan 21 10:11:05 me kernel:  user_statfs+0x54/0xa0
Jan 21 10:11:05 me kernel:  __se_sys_statfs+0x25/0x60
Jan 21 10:11:05 me kernel:  do_syscall_64+0x5b/0x170
Jan 21 10:11:05 me kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Jan 21 10:11:05 me kernel: RIP: 0033:0x7fe2aa8571ab
Jan 21 10:11:05 me kernel: Code: Bad RIP value.
Jan 21 10:11:05 me kernel: RSP: 002b:00007fe221efecf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000089
Jan 21 10:11:05 me kernel: RAX: ffffffffffffffda RBX: 00007fe27258e3a0 RCX: 00007fe2aa8571ab
Jan 21 10:11:05 me kernel: RDX: 00007fe2725869b0 RSI: 00007fe221efed20 RDI: 00007fe2689573a0
Jan 21 10:11:05 me kernel: RBP: 00007fe221efee80 R08: 00007fe29713ee58 R09: 00007fe29713ee60
Jan 21 10:11:05 me kernel: R10: 00007fe29714e078 R11: 0000000000000246 R12: 00007fe268957040
Jan 21 10:11:05 me kernel: R13: 00007ffc0f96f75f R14: 00007fe221eff700 R15: 000000000000001e
Jan 21 10:11:05 me kernel: pool            D    0 10813   5584 0x00000084

There's also this:

Jan 21 10:11:05 me kernel: OOM killer enabled.
Jan 21 10:11:05 me kernel: Restarting tasks ... done.
Jan 21 10:11:05 me systemd-sleep[23193]: Failed to suspend system. System resumed again: Device or resource busy
Jan 21 10:11:05 me kernel: PM: suspend exit
Jan 21 10:11:05 me systemd[1]: systemd-suspend.service: Main process exited, code=exited, status=1/FAILURE
Jan 21 10:11:05 me systemd[1]: systemd-suspend.service: Failed with result 'exit-code'.
Jan 21 10:11:05 me systemd[1]: Failed to start Suspend.
Jan 21 10:11:05 me systemd[1]: Dependency failed for Suspend.
Jan 21 10:11:05 me systemd[1]: suspend.target: Job suspend.target/start failed with result 'dependency'.
Jan 21 10:11:05 me audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Jan 21 10:11:05 me systemd[1]: Stopped target Sleep.
Jan 21 10:11:05 me kernel: audit: type=1130 audit(1548061865.860:643): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Jan 21 10:11:05 me systemd-logind[510]: Operation 'sleep' finished.

According to pacman -Qi systemd, I got version 240.34-3.

I don't know if there's a causal relationship between fusermount and the symptoms but I reckon there is, due to all the mentions of fuse in journalctl.

This issue is mentioned here with the latest non-automated reply in 2012 suggesting to unmounting the remote filesystem before suspending; but that's what I did before the machine froze.

Here is another report of the issue, not containing a workaround or solution.

The answer to this question, while being accepted and upvoted, does not contain actionable advice for me on how to avoid the issue in the future.

2

My gut feeling on this is that there is some caching in sshfs which is still being flushed (many) seconds after you unmounted.

It would be legitimate for a kernel thread to refuse to sleep while attempting to flush a cache, especially where that requires a network connection.

I can't find documentation on whether or not sync will flush caches for fusermount file systems, but do try this first. Ie:

fusermount -u ~/sshfs_mount
sync
systemctl suspend

You could also try mounting the sshfs with -o cache=no as mentioned here:

https://superuser.com/questions/542444/ubuntu-sshfs-doesnt-sync

This might hurt performance with sshfs though.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.