你的问题:“一个无法访问的网络文件系统”是一个众所周知的例子,它会触发linux挂起的任务这与僵尸进程完全不一样(杀死父PID不会做任何事情)
挂起任务是触发系统调用的任务,该系统调用会导致内核出现问题,从而导致系统调用永远不会返回。
主要特点是任务被调度程序声明为“D”状态,这意味着程序处于不可中断状态。这意味着您无法阻止您的程序:您可以触发任务的所有信号,但它不会响应。启动数百个 SIGTERM/SIGKILL 没有任何作用!
我的旧内核就是这种情况:当我的 nfs 服务器崩溃时,我需要重新启动客户端以终止使用文件系统的任务。 IS很久以前就编译过了(我的硬盘上仍然有构建树)在配置过程中我在 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.
这也适用于内核线程:例如:为熔断文件系统上的文件创建一个循环设备。然后使控制熔丝文件系统的用户空间程序崩溃!
你应该得到一个Ktread,其名称的形式为loopX(X通常对应于你的环回设备号)!
网页链接:
https://unix.stackexchange.com/questions/5642/what-if-kill-9-does-not-work 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 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://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/1189978
http://comments.gmane.org/gmane.linux.kernel.cifs/7674 http://comments.gmane.org/gmane.linux.kernel.cifs/7674 (这个情况和你的情况很相似)
对于您的三个问题:您有答案:这可能是由于 vfs linux 内核层中的一个众所周知的错误! (没有 CIFS 超时)