From 37b79d06f80202105cb6d74498e39a5d17724714 Mon Sep 17 00:00:00 2001 From: smheidrich Date: Mon, 24 Sep 2018 23:26:42 +0200 Subject: Docs: add section on interrupted connections Also rename "SSHFS hangs" section to something more specific to differentiate it from this new section. Cf. issues #77 and #3. --- sshfs.rst | 32 ++++++++++++++++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/sshfs.rst b/sshfs.rst index 8d17fc5..1446555 100644 --- a/sshfs.rst +++ b/sshfs.rst @@ -243,8 +243,8 @@ errors which will make programs like `mv(1)` attempt to actually move the file after the failed rename. -SSHFS hangs -~~~~~~~~~~~ +SSHFS hangs for no apparent reason +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In some cases, attempts to access the SSHFS mountpoint may freeze if no filesystem activity has occured for some time. This is typically @@ -253,6 +253,34 @@ without SSHFS being informed about that. As a workaround, you can try to mount with ``-o ServerAliveInterval=15``. This will force the SSH connection to stay alive even if you have no activity. + +SSHFS hangs after the connection was interrupted +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +By default, network operations in SSHFS run without timeouts, mirroring the +default behavior of SSH itself. As a consequence, if the connection to the +remote host is interrupted (e.g. because a network cable was removed), +operations on files or directories under the mountpoint will block until the +connection is either restored or closed altogether (e.g. manually). +Applications that try to access such files or directories will generally appear +to "freeze" when this happens. + +If it is acceptable to discard data being read or written, a quick workaround +is to kill the responsible ``sshfs`` process, which will make any blocking +operations on the mounted filesystem error out and thereby "unfreeze" the +relevant applications. Note that force unmounting with ``fusermount -zu``, on +the other hand, does not help in this case and will leave read/write operations +in the blocking state. + +For a more automatic solution, one can use the ``-o ServerAliveInterval=15`` +option mentioned above, which will drop the connection after not receiving a +response for 3 * 15 = 45 seconds from the remote host. By also supplying ``-o +reconnect``, one can ensure that the connection is re-established as soon as +possible afterwards. As before, this will naturally lead to loss of data that +was in the process of being read or written at the time when the connection was +interrupted. + + Mounting from /etc/fstab ======================== -- cgit v1.2.3