3

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.

0

1 Answer 1

3

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.

1
  • 1
    systemctl suspend calls sync internally. I have the same problem with both Keybase and gvfsd. I think its a problem with the FUSE system, but unmounting all FUSE file systems and then using systemctl suspend (and not sudo pm-suspend that I was doing before) apparently works around the problem.
    – Guss
    Nov 23, 2023 at 9:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .