GentooボックスとWindowsボックスを持つ小さなローカルネットワークがあります。次のようなコマンドを使用して、Windowsボックスで発生した共有をGentooボックスにマウントします。
mount -t cifs -o username=WindowsUsername,password=thepassword,uid=pistos //192.168.0.103/Users /mnt/windowsbox
ほとんどの場合、すべてが正常に機能し、問題なく読み書きできます。ただし、数週間ごとに、接続またはマウントポイントが停止またはハングし、マウントポイントにアクセスしようとするプロセスがD状態(ディスクまたはI/O待機)でスタックするようになります。これらのプロセスは、TERMおよびKILLシグナルの影響を受けなくなります。 Windowsボックスをネットワークから切断して再接続しても、役に立ちません。フリーズ状態は5分以上続きます。名前を付けて保存ダイアログ、ls
コマンドなどがフリーズするため、本当にイライラして通常の作業の邪魔になります。マウントポイントでumount
を発行すると、ハングするか、マウントポイントが使用中であることを報告します。最終的に、デッドステートが自動的に解決し、マウントポイントがアンマウントされるか、遅延なくumount
が可能になります。
私の推測では、これは接続/マウントがアイドル状態になったとき、またはWindowsマシンがアイドル状態になったときに起こります。よくわかりません。
なぜこれが起こっているのですか?それを防ぐにはどうすればよいですか?または、どうすればこれらのD状態プロセスを自由に強制終了できますか?
関連する可能性があります: CIFSマウントは読み取り時にハングします
問題が発生している理由はわかりませんが、回避策として、touch /mnt/windowsbox/keepalive.txt
またはecho "I am still alive." >/mnt/windowsbox/keepalive.txt
毎分cron経由で実行しますか?これにより、接続はアクティブなままになります。
私もこれに数か月ごとに出会います。 Sudo umount -l
が私の回避策です。 https://stackoverflow.com/a/96288/2097284
ネットワークに問題があり、Windowsボックスが7以上で実行されている場合は、お読みください
レジリエントオープンスカベンジャータイマー[MS-SMB2](デフォルト300秒)
cIFSタイムアウトの詳細
http://blogs.msdn.com/b/openspecification/archive/2013/03/19/cifs-and-smb-timeouts-in-windows.aspx
問題に自動回復動作がある場合は、タイムアウトを探します...
別の潜在的な答えは、cronを介して定期的にマウント上のファイルに書き込むことを提案しました。代わりに、smbclientプログラムを使用して共有に接続し、切断することをお勧めします。
私はそれを達成するためにこのようなbashスクリプトを書きました:
#!/bin/bash
su usernamehere -c "smbclient \\\\\\\\\\\\\\\\servernamehere\\\\\\\\sharenamehere passwordhere -c exit" >/dev/null 2>&1
このコマンドは、共有への新しい接続を作成してから、exitコマンドを実行し、コマンドラインで確立した接続をただちにシャットダウンします。バックスラッシュはエスケープする必要があり、二重引用符で囲まれた文字列内ではエスケープをエスケープする必要があるため、サーバー名の前に8つのスラッシュと共有名の前に4つのスラッシュが必要です。おそらくこれを行うためのよりスマートな方法がありますが、これはうまくいくようです。
おそらく、一度に数分間接続を開いたままにしておくことで、これをさらに信頼性の高いものにする方法があるかもしれませんが、それは私のリーグから少しずれています。