嘗試訪問通過CIFS掛接的遠程文件夾掛起時掛起

Question

此問題是that question的擴展。

再一次：我的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. 我該如何檢查文件夾是否存在並且不會被鎖定？

Answer 1

你的問題：「無法訪問網絡文件系統」是一個非常著名的例子引發的Linux 掛任務這是不是在所有相同的殭屍進程（殺死父PID什麼都不會做）

一個掛起的任務，是觸發系統調用的任務，這個系統調用在內核中導致問題，以致系統調用永不返回。 主要的特點是任務由調度程序在「D」狀態中聲明，這意味着程序處於不可中斷狀態。這意味着你無法阻止你的程序：你可以觸發所有的信號到任務，它不會迴應。發射數百個SIGTERM/SIGKILL什麼都不做！

這是我的舊內核的情況：當我的nfs服務器崩潰時，我需要重新啓動客戶端以使用文件系統終止任務。我很久以前編譯了它（我的硬盤上仍有構建樹），在配置期間我在lib/Kconfig中看到了這個。調試：

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. 

它只是提出來檢測檢測等塔什或恐慌：我不籤，如果最近的內核實際上是可以解決的問題（這似乎是你的問題的情況下），但我認爲它不值得啓用它。

還有第二個問題：通常，在檢測後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. 

這也適用於內核線程：例如：使一個循環設備到文件在熔絲文件系統上。然後崩潰控制熔絲文件系統的用戶空間程序！ 你應該得到一個名字爲loopX的Ktread（X通常對應於你的環回設備號）HUNGing！

網站鏈接：

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（這是一個類似的情況到你的）

在你的情況下的三個問題：你有答案：這可能是由於什麼可能是一個衆所周知的bug在vfs linux內核層！ （沒有CIFS超時）