After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 539593 - SSH mount becomes unresponsive after a while it has been idle
SSH mount becomes unresponsive after a while it has been idle
Status: RESOLVED INVALID
Product: gvfs
Classification: Core
Component: sftp backend
git master
Other Linux
: Normal major
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2008-06-22 13:50 UTC by Cosimo Cecchi
Modified: 2014-05-31 12:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Cosimo Cecchi 2008-06-22 13:50:32 UTC
Don't know if this is the same bug as bug 515217.

- Connect to a SSH share
- do whatever you want with it
- leave it idle for some time (I experienced this after ~20-30 min I think)
- try to access the share again
- you won't be able to get any result from the share

I.e. the app accessing it will just lock if it's doing sync i/o (GEdit does), or will just seem to do nothing if it's doing async i/o (like Nautilus does).
Comment 1 Sebastien Bacher 2009-01-26 15:33:34 UTC
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/310932 describes a similar issue when using smb
Comment 2 Ross Lagerwall 2014-05-31 12:40:48 UTC
(In reply to comment #0)
> Don't know if this is the same bug as bug 515217.
> 
> - Connect to a SSH share
> - do whatever you want with it
> - leave it idle for some time (I experienced this after ~20-30 min I think)
> - try to access the share again
> - you won't be able to get any result from the share
> 
> I.e. the app accessing it will just lock if it's doing sync i/o (GEdit does),
> or will just seem to do nothing if it's doing async i/o (like Nautilus does).

We just rely on TCP's connection handling (actually done by the underlying ssh process). Thus if there is a firewall that decides to drop the connection, when you next try to send something, nothing will happen because no TCP FIN was ever received for the connection. After a while, the attempt to contact the sftp server fails at the TCP level and the gvfs backend cleanly unmounts.

It is still possible to unmount the sftp backend when it is in this state.

If you have to work around a firewall dropping connections, the best solution is to let ssh send application-level keepalive messages. Add the following to your ssh config:
Host somehost
   ServerAliveInterval 60 (some appropriate value here)

I think it is best for gvfs to just use the TCP and ssh defaults and not try to do anything too clever here rather than introducing another set of defaults which may not be appropriate in all situations.

(GEdit seems to handle the situation better now by saving asynchronously.)