GNOME Bugzilla – Bug 515217
gvfs sftp mount stalls when TCP connection has been reset
Last modified: 2014-05-31 12:17:26 UTC
I'm connecting to a remote SSH server through a firewall. The firewall drops inactive TCP connections after 5 minutes. Gvfs doesn't notice it when the connection is being dropped. When Nautilus or the GTK filechooser try to open the mount they become unresponsive. Nautilus freezes completely and I have to kill and restart it. I have to unmount and remount the gvfs location to be able to access files again. Gvfs should notice when a sftp connection is closed and reconnect to it. Additionally it should try to keep the connection alive, so that it won't be closed. On a sidenote: Overall, I'm quite impressed at the rate at which gio/gvfs is maturing. Is is already nice to work with and I haven't encountered much problems :) I'm running Ubuntu Hardy Heron i386 with Gnome 2.21.90
You can add ServerAliveInterval 5 ServerAliveCountMax 0 to ~/.ssh/config I'm not sure how much of this internal stuff should really be exposed. best regards, Christian Neumair
We should be able to detect when the connection drops though, and clean ourselves up (ie. exit the backend daemon, until bug 511802 is fixed).
*** Bug 539964 has been marked as a duplicate of this bug. ***
Furthermore, even if the whole sftp backend goes tits-up nautilus should ideally not hang.
(In reply to comment #4) > Furthermore, even if the whole sftp backend goes tits-up nautilus should > ideally not hang. > +1. Nautilus hanging is absolutely unacceptable. Even the panel frequently hangs when the connection is dropped. Wasn't it decided that using blocking dbus calls on the desktop was poor practice and should be avoided at all costs (http://smcv.pseudorandom.co.uk/2008/11/nonblocking/). Something is clearly wrong when even the core desktop shell isn't using dbus properly.
Still a problem. My use case: I started copying some pictures to my server. Seeing that it'd take over 2 hours, I connected the local network cable instead of wireless. When I saw that gvfs didn't migrate to the better connection, I disconnected from the wireless. That made nautilus/gvfs hang very badly. And it never recovered (impossible to unmount as well), I had to kill gvfsd-sftp.
This looks like a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=325979
I can not reproduce the stalling in Nautilus. Now Nautilus seem to get the error: “Opps something went wrong. Unhandled error message: Internal error: The underlying SSH process died” After which a reconnection can now be done without having to kill the gvfs backend. Can anyone else still reproduce this issue on a current version of gvfs?
Yeah, the hangs appear to have been fixed. If the remote end exits relatively cleanly, gvfsd-sftp correctly detects it (because a TCP FIN packet is sent). If the connection is dropped by a firewall, then there's no TCP FIN to detect that the connection is closed and so it takes a while for the TCP connection to timeout. However, it does not hang, and it is possible to unmount the sftp connection when it is in this state.