Depois de desmontar um sistema de arquivos remoto fusermount -u ~/sshfs_mount/
e chamar systemctl suspend
meu Arch Linux 4.20.2 congelou por cerca de 20 segundos.
Após esses 20 segundos, o sistema voltou a responder (não suspendeu). Então tentei suspender mais uma vez, o que deu certo dessa vez.
Verificando journalctl
, encontrei muitas dessas mensagens:
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
Também tem isso:
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.
De acordo com pacman -Qi systemd
, eu tenho a versão 240.34-3.
Não sei se há uma relação causal entre fusermount
e os sintomas, mas acho que sim, devido a todas as menções de fusível em journalctl
.
Este problema é mencionado aqui com a última resposta não automatizada em 2012 sugerindo desmontar o sistema de arquivos remoto antes de suspender; mas foi o que fiz antes de a máquina congelar.
Aqui está outro relatório do problema, que não contém uma solução alternativa ou solução.
A resposta a esta pergunta , embora seja aceita e votada, não contém conselhos acionáveis para mim sobre como evitar o problema no futuro.
Meu pressentimento sobre isso é que há algum cache em sshfs que ainda está sendo liberado (muitos) segundos depois que você desmontou.
Seria legítimo que um thread do kernel se recusasse a dormir enquanto tenta liberar um cache, especialmente quando isso requer uma conexão de rede.
Não consigo encontrar documentação sobre se
sync
irá ou não liberar caches parafusermount
sistemas de arquivos, mas tente isso primeiro. Ou seja:Você também pode tentar montar o sshfs
-o cache=no
como mencionado aqui:https://superuser.com/questions/542444/ubuntu-sshfs-doesnt-sync
Isso pode prejudicar o desempenho com sshfs.