Linux上进程的kill -9怎么可能没有效果？答案

【问题标题】：How is it possible that kill -9 for a process on Linux has no effect?Linux上进程的kill -9怎么可能没有效果？
【发布时间】：2010-10-16 05:38:00
【问题描述】：

我正在编写一个插件来在您访问网站时自动突出显示文本字符串。就像高亮搜索结果一样，但是是自动的，并且适用于许多单词；它可以用于过敏症患者，让文字真正脱颖而出，例如，当他们浏览美食网站时。

但是我有问题。当我尝试关闭一个空的、新鲜的 FF 窗口时，它会以某种方式阻止整个过程。当我终止进程时，所有窗口都消失了，但 Firefox 进程仍然存在（父 PID 为 1，不听任何信号，有很多资源打开，仍然占用 CPU，但不会让步）。

那么两个问题：

一个进程怎么可能不监听 kill -9（既不是用户也不是 root）？
除了重启我还能做什么？

[编辑]这是有问题的过程：

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
digulla  16688  4.3  4.2 784476 345464 pts/14  D    Mar28  75:02 /opt/firefox-3.0/firefox-bin

与ps -ef | grep firefox相同

UID        PID  PPID  C STIME TTY          TIME CMD
digulla  16688     1  4 Mar28 pts/14   01:15:02 /opt/firefox-3.0/firefox-bin

这是唯一剩下的过程。如您所见，它不是僵尸，它在奔跑！它不听kill -9，无论我是按PID还是名称杀死！如果我尝试与strace 连接，那么strace 也会挂起并且无法被杀死。也没有输出。我的猜测是 FF 在某些内核例程中挂起，但是哪个？

[EDIT2] 基于 sigjuice 的反馈：

ps axopid,comm,wchan

可以显示一个进程挂在哪个内核例程中。就我而言，有问题的插件是 Beagle Indexer (openSUSE 11.1)。禁用插件后，FF 又是一只又快又快乐的狐狸了。

【问题讨论】：

我认为“与编程无关”很苛刻。如果 Aaron 自己修改了 firefox 代码，并问了这个关于 linux 的确切问题，那么这将与编程有关。操作系统内核行为肯定与编程有某些有关吗？
@Aaron STAT 列显示“D”，意思是“不间断睡眠”。处于这种状态的进程根本无法被杀死。您的主目录是 NFS 挂载还是 Firefox 以其他方式访问 NFS 目录？
@Aaron "ps axopid,comm,wchan" 可能会告诉你 Firefox 卡在了哪个内核例程中。
这个是编程相关的，因为它可能非常适合shell脚本，例如在构建系统或自动化测试框架中。
U&L 上的此副本的副本。可以合并吗？

标签： linux process sysadmin kill

【解决方案1】：

我最近陷入了Double Fork 的陷阱，并在最终找到我的答案之前登陆了此页面。即使问题不一样，症状也是一样的：

WYKINWYT : 你杀的不是你想的

下面显示了基于 SNMP 守护程序示例的最小测试代码

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

int main(int argc, char* argv[])
{
    //We omit the -f option (do not Fork) to reproduce the problem
    char * options[]={"/usr/local/sbin/snmpd",/*"-f","*/-d","--master=agentx", "-Dagentx","--agentXSocket=tcp:localhost:1706",  "udp:10161", (char*) NULL};

    pid_t pid = fork();
    if ( 0 > pid ) return -1;

    switch(pid)
    {
        case 0: 
        {   //Child launches SNMP daemon
            execv(options[0],options);
            exit(-2);
            break;
        }
        default: 
        {
            sleep(10); //Simulate "long" activity

            kill(pid,SIGTERM);//kill what should be child, 
                              //i.e the SNMP daemon I assume
            printf("Signal sent to %d\n",pid);

            sleep(10); //Simulate "long" operation before closing
            waitpid(pid);
            printf("SNMP should be now down\n");

            getchar();//Blocking (for observation only)
            break;
        }
    }
    printf("Bye!\n");
}

在第一阶段，主进程 (7699) 启动了 SNMP 守护进程 (7700)，但我们可以看到这个进程现在是Defunct/Zombie。在旁边我们可以看到另一个进程 (7702) 带有我们指定的选项

[nils@localhost ~]$ ps -ef | tail
root       7439      2  0 23:00 ?        00:00:00 [kworker/1:0]
root       7494      2  0 23:03 ?        00:00:00 [kworker/0:1]
root       7544      2  0 23:08 ?        00:00:00 [kworker/0:2]
root       7605      2  0 23:10 ?        00:00:00 [kworker/1:2]
root       7698    729  0 23:11 ?        00:00:00 sleep 60
nils       7699   2832  0 23:11 pts/0    00:00:00 ./main
nils       7700   7699  0 23:11 pts/0    00:00:00 [snmpd] <defunct>
nils       7702      1  0 23:11 ?        00:00:00 /usr/local/sbin/snmpd -Lo -d --master=agentx -Dagentx --agentXSocket=tcp:localhost:1706 udp:10161
nils       7727   3706  0 23:11 pts/1    00:00:00 ps -ef
nils       7728   3706  0 23:11 pts/1    00:00:00 tail

在模拟 10 秒后，我们将尝试杀死我们知道的唯一进程 (7700)。我们终于用 waitpid() 成功了。但是进程 7702 仍然在这里

[nils@localhost ~]$ ps -ef | tail
root       7431      2  0 23:00 ?        00:00:00 [kworker/u256:1]
root       7439      2  0 23:00 ?        00:00:00 [kworker/1:0]
root       7494      2  0 23:03 ?        00:00:00 [kworker/0:1]
root       7544      2  0 23:08 ?        00:00:00 [kworker/0:2]
root       7605      2  0 23:10 ?        00:00:00 [kworker/1:2]
root       7698    729  0 23:11 ?        00:00:00 sleep 60
nils       7699   2832  0 23:11 pts/0    00:00:00 ./main
nils       7702      1  0 23:11 ?        00:00:00 /usr/local/sbin/snmpd -Lo -d --master=agentx -Dagentx --agentXSocket=tcp:localhost:1706 udp:10161
nils       7751   3706  0 23:12 pts/1    00:00:00 ps -ef
nils       7752   3706  0 23:12 pts/1    00:00:00 tail

在给 getchar() 函数一个字符后，我们的主进程终止，但 pid 为 7002 的 SNMP 守护进程仍然在这里

[nils@localhost ~]$ ps -ef | tail
postfix    7399   1511  0 22:58 ?        00:00:00 pickup -l -t unix -u
root       7431      2  0 23:00 ?        00:00:00 [kworker/u256:1]
root       7439      2  0 23:00 ?        00:00:00 [kworker/1:0]
root       7494      2  0 23:03 ?        00:00:00 [kworker/0:1]
root       7544      2  0 23:08 ?        00:00:00 [kworker/0:2]
root       7605      2  0 23:10 ?        00:00:00 [kworker/1:2]
root       7698    729  0 23:11 ?        00:00:00 sleep 60
nils       7702      1  0 23:11 ?        00:00:00 /usr/local/sbin/snmpd -Lo -d --master=agentx -Dagentx --agentXSocket=tcp:localhost:1706 udp:10161
nils       7765   3706  0 23:12 pts/1    00:00:00 ps -ef
nils       7766   3706  0 23:12 pts/1    00:00:00 tail

结论

我们忽略了双叉机制的事实让我们认为kill动作没有成功。但实际上我们只是杀错了进程！！

通过添加 -f 选项（Do Not (Double) Fork）一切都按预期进行

【讨论】：

【解决方案2】：

再次检查 parent-id 是否真的是 1。如果不是，这是firefox，首先尝试sudo killall -9 firefox-bin。之后，尝试使用 sudo killall -9 [process-id] 单独杀死特定的进程 ID。

一个进程怎么可能不听kill -9（既不是用户也不是root）？

如果一个进程已经去了<defunct>，然后变成了一个父级为1的zombie，你不能手动杀死它；只有init 可以。僵尸进程已经死亡并消失了——它们已经失去了被杀死的能力，因为它们不再是进程，只有一个进程表条目及其相关的退出代码，等待收集。您需要杀死父级，并且由于显而易见的原因，您不能杀死init。

但请参阅here 了解更多一般信息。重启自然会杀死一切。

【讨论】：

实际上zombie不是一个进程，而是一个进程表项，存在的唯一目的是向父进程发送SIGCHLD。 Init 自动加入，所以你不能真正拥有 PPID==1 的僵尸。
我的理解是 kill -9 会在不问很多问题的情况下从进程表中删除进程。但似乎一个过程可以以某种方式阻止这种情况。怎么样？
@vartec：你说得对，我的措辞不是很好。如果您想编辑它，请继续。 @Aaron：已死的进程不听终止信号（没有什么可杀死的，它们仍然需要被收割，所以它们还不能消失）。
编辑澄清僵尸不再是一个实际的进程。

【解决方案3】：

如 OP 的 cmets 中所述，D 的进程状态 (STAT) 表示进程处于“不间断睡眠”状态。在现实世界中，这通常意味着它正在等待 I/O，并且在 I/O 操作完成之前不能/不会做任何事情（包括死亡）。

处于D 状态的进程通常只会在操作完成之前存在几分之一秒，然后它们会返回到R/S。根据我的经验，如果一个进程卡在D 中，它通常会尝试与无法访问的 NFS 或其他远程文件系统进行通信，尝试访问发生故障的硬盘驱动器，或者通过易碎的方式使用某些硬件设备驱动。在这种情况下，恢复并允许进程终止的唯一方法是让 fs/驱动器/硬件备份并运行，以便 I/O 可以完成，或者放弃并重新启动系统。在 NFS 的特定情况下，挂载也可能最终超时并从 I/O 操作返回（带有失败代码），但这取决于挂载选项，并且 NFS 挂载设置为永远等待是很常见的.

这与僵尸进程不同，僵尸进程的状态为Z。

【讨论】：

是的，可怕的磁盘睡眠 :) +1，这是一个清晰的答案。
嗯。我不认为有办法在 NFS/SMB/等上设置超时。在你进入他的处境之后上山？
您可能还会看到由于内核错误而卡在 D 中的内容。
查看发生了什么的好方法是运行ps -o pid,wchan 1234（插入相关的pid），它会告诉你它卡在内核中的哪个等待通道 .你可以在错误报告中使用它，或者在谷歌上使用它，它可能会给你一个线索——不管它是卡在 NFS 中，还是其他驱动程序等等。
好答案！！！僵尸进程也不能被杀死（实际上，它是僵尸）你必须杀死父进程，所以僵尸进程得到一个总是在等待（2）的新父进程（init），它最终在父进程的等待（2）中死亡)。

【解决方案4】：

是否有可能在您杀死它时重新启动该进程（例如通过 init）？

您可以轻松检查。如果kill -9 PID 之后的 PID 相同，则该进程没有被杀死，但如果它已更改，则该进程已重新启动。

【讨论】：

【解决方案5】：

您也可以执行 pstree 并杀死父级。这样可以确保您获得整个有问题的进程树，而不仅仅是叶子。

【讨论】：

【解决方案6】：

sudo killall -9 firefox

应该有效

编辑：[PID] 更改为 firefox

【讨论】：

如果问题与多个实例有关，那应该将它们全部关闭，而 kill -9 PID 只杀死指定的实例。
有趣。当我写我的 cmets 时，答案是错误的。现在答案是正确的，我的 cmets 已经过时了。但是，答案没有编辑历史记录。
如果它让你开心，Jorg，我会进行编辑。我们今天过得很糟糕，是吗？
这更多是对网站行为的观察。可以编辑帖子的事实是 SO 起作用的原因。但是，我不知道一个人可以在不显示为已编辑的情况下编辑帖子，这有点奇怪。
我认为 'edit X mins ago' 会在大约一分钟后出现，这就是为什么最初没有将已编辑的答案标记为已编辑的原因。我也注意到了。

【解决方案7】：

ps -ef | grep 火狐；你可以看到 3 个进程，将它们全部杀死。

【讨论】：