4

この質問はその質問の延長です。

繰り返しますが、私はCentOS 6.0で作業しており、次のものをマウントしたリモートwin7フォルダーがあります。

mount -t cifs //PC128/mnt /media/net -o "username=WORKGROUP\user,password=pwd,rw,noexec,soft,uid=user,gid=user"

リモート フォルダが利用できない場合 (ネットワーク ケーブルが引き抜かれている場合など)、リモート フォルダにアクセスしようとすると、作業中のアプリケーションがロックされます。最初に、QDir::exists() が 20 ～ 90 秒間ロックを引き起こしたことを検出しました (そのような違いの理由はまだわかりません)。さらに、stat() 関数を呼び出すとアプリケーションがロックされることがわかりました。

上記のトピックで提供されたアドバイスに従い、QDir::exists() 呼び出し (および後で - stat() 関数の呼び出し) を別のスレッドに移動しましたが、これで問題は解決しませんでした。接続が突然失われると、アプリケーションは依然としてハングします。Qt トレースは、ロックがカーネルのどこかにあることを示しています。

0   __kernel_vsyscall
1   __xstat64@GLIBC_2.1               /lib/libc.so.6
2   QFSFileEnginePrivate::doStat      stat.h

また、フォルダー自体にアクセスする前に、リモート共有がまだマウントされているかどうかを確認しようとしましたが、役に立ちませんでした。次のようなアプローチ:

mount | grep /media/net

ネットワークへのアクティブな接続がない場合でも、共有フォルダーがまだマウントされていることを示しています。

次のようなフォルダ ステータスの違いを確認します。

stat -fc%t:%T /media/net/ != stat -fc%t:%T /media/net/..

また、約 20 秒間ハングします。

だから私はいくつかの質問があります：

  1. CIFS タイムアウトを変更する方法はありますか? 調べてみましたが、適切なパラメータもCIFS構成もないようです。
  2. リモート フォルダがまだマウントされていて、ロックされていないかどうかを確認するにはどうすればよいですか?
  3. フォルダが存在し、ロックされていないことを確認するにはどうすればよいですか?
4

2 に答える 2

8

あなたの問題：「到達不能なネットワークファイルシステム」は、ゾンビプロセスとはまったく異なるLinuxハングタスクをトリガーする非常によく知られた例です（親PIDを殺しても何も起こりません）

ハングしたタスクとは、カーネルに問題を引き起こすシステム コールをトリガーしたタスクであり、システム コールは決して戻りません。主な特徴は、タスクがスケジューラによって「D」状態で宣言されていることです。これは、プログラムが中断できない状態にあることを意味します。これは、プログラムを停止するために何もできないことを意味します。タスクへのすべての信号をトリガーできますが、応答しません。何百もの SIGTERM/SIGKILL を起動しても何も起こりません!

これは古いカーネルの場合です。nfs サーバーがクラッシュした場合、クライアントを再起動して、ファイルシステムを使用しているタスクを強制終了する必要があります。私はずっと前にそれをコンパイルしました（私はまだ私のhddにビルドツリーを持っています）そして構成中に私はlib/Kconfig.debugでこれを見ました：

config DETECT_HUNG_TASK
    bool "Detect Hung Tasks"
    depends on DEBUG_KERNEL
    default LOCKUP_DETECTOR
    help
      Say Y here to enable the kernel to detect "hung tasks",
      which are bugs that cause the task to be stuck in
      uninterruptible "D" state indefinitiley.

      When a hung task is detected, the kernel will print the
      current stack trace (which you should report), but the
      task will stay in uninterruptible state. If lockdep is
      enabled then all held locks will also be reported. This
      feature has negligible overhead.

検出時にそのようなタッシュまたはパニックを検出することを提案しているだけでした: 最近のカーネルが実際に問題を解決できるかどうかは確認していません(あなたの質問の場合のようです)が、それを有効にする価値はなかったと思います.

2 番目の問題があります。通常、検出は 120 秒後に行われますが、Konfig オプションも見ました。

config DEFAULT_HUNG_TASK_TIMEOUT
    int "Default timeout for hung task detection (in seconds)"
    depends on DETECT_HUNG_TASK
    default 120
    help
      This option controls the default timeout (in seconds) used
      to determine when a task has become non-responsive and should
      be considered hung.

      It can be adjusted at runtime via the kernel.hung_task_timeout_secs
      sysctl or by writing a value to
      /proc/sys/kernel/hung_task_timeout_secs.

      A timeout of 0 disables the check.  The default is two minutes.
      Keeping the default should be fine in most cases.

これはカーネル スレッドでも機能します。例: ヒューズ ファイルシステム上のファイルにループ デバイスを作成します。次に、fuse ファイルシステムを制御するユーザー空間プログラムをクラッシュさせます! 名前が loopX の形式の Ktread を取得する必要があります (X は通常、ループバック デバイス番号に対応します)。

Webリンク：

https://unix.stackexchange.com/questions/5642/what-if-kill-9-does-not-work (ultrasawblade によって書かれた回答を見てください)

http://www.linuxquestions.org/questions/linux-general-1/kill-a-hung-task-when-kill-9-doesn 't-help-697305/

http://forums-web2.gentoo.org/viewtopic-t-811557-start-0.html

http://comments.gmane.org/gmane.linux.kernel/1189978

http://comments.gmane.org/gmane.linux.kernel.cifs/7674 (これはあなたに似たケースです)

あなたの 3 つの質問の場合: 答えがあります: これはおそらく、vfs Linux カーネル層のよく知られたバグによるものでしょう! (CIFS タイムアウトはありません)

于 2013-09-30T18:53:29.233 に答える