On Wed, 7 Jun 2023 at 13:13, Askar Safin <safinaskar@xxxxxxxxx> wrote: > > I found a workaround for sshfs+suspend problem! > > On Tue, Jun 6, 2023 at 5:38 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > Issues remaining: > > > > - if requests are stuck (e.g. network is down) then the requester > > process can't be frozen and suspend will still fail. > > > Solution to both these are probably non-kernel: impacted servers need > > to receive notification from systemd when suspend is starting and act > > accordingly. > > Okay, so you said that the only way to solve the problem "network is > down" is to fix the problem at the sshfs side. Unfortunately, sshfs > project was closed ( https://github.com/libfuse/sshfs ). So the only > remaining option is to use some hack. And I found such a hack! > > I simply added "-o ServerAliveInterval=10" to sshfs command. This will > cause ssh process exit if remote side is unreachable. Thus the bug is > prevented. I tested the fix and it works. > > But this will mean that ssh process will exit in such situation, and > thus sshfs process will exit, too. If this is not what you want, then > also add "-o reconnect" option, this will restart connection if ssh > dies. So the final command will look like this: > > sshfs -o reconnect,ServerAliveInterval=10 ... > > This finally solved the problem for me. > > But one issue still remains: if the network goes down and then you > immediately try to access sshfs filesystem and then you will try to > suspend (and ssh doesn't yet noticed that the network gone down), then > suspend will still fail. If the ServerAliveInterval is set to less than the freeze timeout (20s by default) and you apply the patch and start sshfs like below, then suspend should be reliable. (echo 1 > /proc/self/freeze_late; sshfs ...) Thanks, Miklos
