解決策 1:
-o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3 を使用
組み合わせ ServerAliveInterval=15,ServerAliveCountMax=3 ネットワークが 1 分間停止すると、I/O エラーが発生します。これは重要ですが、ほとんど文書化されていません。 ServerAliveInterval の場合 オプションはデフォルトのまま (つまり、アライブ チェックなし) であり、sshfs が reconnect を取得した後でも、I/O ハングを経験するプロセスは無期限にスリープしているように見えます。 編。これは無駄な行為だと思います。
つまり -o reconnect で何が起こるか ServerAliveInterval を割り当てずに sshが再接続された場合、I/Oは成功するか、アプリケーションを無期限にハングさせるということです。その結果、典型的なアプリケーションは完全にハングアップします。 I/O がエラーを返してアプリケーションを再開できるようにしたい場合は、ServerAliveInterval=1 が必要です。 以上。
ServerAliveCountMax=3 とにかくデフォルトですが、読みやすくするために指定したいと思います.
解決策 2:
autossh と autofs のヒントをありがとう。
しかし、私の直接の目的のために、あまり文書化されていない、もっと単純な解決策を見つけました:
sshfs -o reconnect server:/path/to/mount
解決策 3:
Autossh は、ssh が停止したかトラフィックの通過を停止したことに気付くと、ssh セッションを自動的に再接続します。これは単に自動化された ssh であるため、異なる IP やサスペンドから動作します (ラップトップが別の LAN で起動した場合でも)。
解決策 4:
できることの 1 つは、autofs を介してファイルシステムをマウントすることです。 autofs は、ファイルシステムがマウントされるディレクトリで何かを使用するときに、ファイルシステムをマウントするツールです。アクティビティが検出されると、ファイルシステムがマウントされます。ファイルシステムで何も起きていないときは、アンマウントされています。
これを実現するために Google で見つけたハウツーを次に示します。他にもいくつかあります。
解決策 5:
SSHクライアントが接続をドロップしないように構成できたとしても、指定された非アクティブ期間の後にサーバーがそうするように構成されている可能性があり、それをオーバーライドできないため、そうではないと思います。できたとしても、接続を再開しないと、サーバーはハングしたままになり、時間の経過とともにサーバー リソースが大幅に浪費される可能性があります。
より良いテクニックは、コンピューターをサスペンドする前にファイルシステムをアンマウントし、コンピューターが再び起動したときに再マウントすることだと思います。これを行うメカニズムは、コンピューターをどのようにサスペンドするかによって異なります。私は tuxonice カーネルを使用しており、このようなことを行うために、次のようなディレクティブがあります
Unmount /mnt/sshfs
/etc/hibernate/common.conf で .