sshfs icon indicating copy to clipboard operation
sshfs copied to clipboard
verified publisher icon libfuse

Abort on network timeout

Open Nikratio opened this issue 8 years ago • 10 comments

We should take a look at the following patch, it may be worth merging:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720455

Nikratio avatar Aug 06 '17 17:08 Nikratio

That would probably solve issue #3

Soukyuu avatar Aug 06 '17 20:08 Soukyuu

I have the same problem. Was the patch implemented? Is it a closed issue?

alexisfrjp avatar May 03 '18 07:05 alexisfrjp

Nope, this is still open. Pull requests welcome :-).

Nikratio avatar May 03 '18 07:05 Nikratio

[email protected] did actually return my email (to the fuse mailing list back in 2013)

Thanks for the patch. How about using existing ssh options for this?

-oServerAliveInterval=30

will disconnect after 90sec of network outage. It will also disconnect when there's no sshfs activity, but together with -oreconnect that should work fine most of the time.

The problem with setting a default timeout is that there's no one value that's suitable for all users. And the safest is no timeout, even though it may not be the most user friendly (ssh also has the timeout disabled by default).

Thanks, Miklos

I've been using those options since then, and it resolved my issue. IMO -oServerAliveInterval=30 is a better default than no timeout, but it's a little late to change that default now.

aerusso avatar Sep 18 '18 21:09 aerusso

If that does indeed solve it, it would be nice if it could be explained in the documentation somewhere, perhaps as an extra section on network timeouts.

smheidrich avatar Sep 19 '18 05:09 smheidrich

@smheidrich Could you give it a shot? Happy to review pull requests :-).

Nikratio avatar Sep 19 '18 08:09 Nikratio

@Nikratio Sure, I'll try to write one this weekend :)

smheidrich avatar Sep 19 '18 15:09 smheidrich

I ran into this today. As I understand, the patch (a9a2d75ab3db7e7fb12368ecf00f5e7599d46921) won't be merged because setting a timeout is not a good choice for everyone. However, it could be useful to have a warning in logs when sshfs is taking a long time.

In my case, it took quite some time to identify that the hanging was caused by sshfs. We use sshfs to mount $HOME ; everything was frozen and no clues in the logs.

maccadia avatar Feb 25 '19 15:02 maccadia

Pull requests are welcome :-).

Nikratio avatar Feb 25 '19 21:02 Nikratio

Unfortunately, I'm not a dev. Let's hope someone will have some time for that. It's not critical anyway.

maccadia avatar Feb 26 '19 07:02 maccadia