centos - 尝试访问安装有 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 trace 显示锁在内核中的某处:

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.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.

它只是建议在检测时检测这种 tash 或 panic:我没有检查最近的内核是否真的可以解决问题(你的问题似乎是这样)，但我认为不值得启用它。

还有第二个问题:通常情况下，检测会在 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 文件系统上的文件创建一个循环设备。然后让控制 fuse 文件系统的用户空间程序崩溃!您应该得到一个 Ktread，其名称的形式为 loopX(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 (这个和你的情况类似)

对于您的三个问题:您有答案:这可能是由于 vfs linux 内核层中一个众所周知的错误造成的! (没有 CIFS 超时)