blocks|key|344496|text|sudo+killall+-9+firefox|type|code-block|depth|inlineStyleRanges|entityRanges|data|syntax|javascript|344497|应该行得通|unstyled|344498|编辑:+PID更改为firefox|344499|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$B|C]]|$1|D|3|E|5|F|7|L|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|F|7|N|8|@]|9|@]|A|$]]]|J|$]]

<pre><code>sudo killall -9 firefox
</code></pre>

Should work

EDIT: [PID] changed to firefox

blocks|key|3334610|text|ps+-ef+%7C+grep+firefox；你可以看到3个进程，杀死它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3334611|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

ps -ef | grep firefox;
and you can see 3 process, kill them all.

blocks|key|3121745|text|仔细检查parent-id是否真的是1。如果不是，这是firefox，首先尝试sudo+killall+-9+firefox-bin。在此之后，尝试使用sudo+killall+-9+[process-id]逐个终止特定的进程ID。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3121746|3121747|进程怎么可能不监听kill+-9+(neiter既不是用户也不是根用户)？|blockquote|3121748|3121749|3121750|如果一个进程已经<defunct>了，然后变成了一个父进程为1的，您不能手动终止它；只有init可以。僵尸进程已经死了--它们已经失去了被杀死的能力，因为它们不再是进程，只有一个进程表条目及其相关的退出代码，等待被收集。你需要杀死父母，但你不能因为显而易见的原因而杀死init。|3121751|但要了解更多一般信息，请参阅。重启自然会杀死所有东西。|3121752|entityMap^0|R|7|13|R|24|S|0|0|0|0|0|8|9|18|4|3Q|4|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|Z|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|10|8|@]|D|@]|E|$]]|$1|K|3|-4|5|6|7|11|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|12|8|@$9|13|A|14|B|C]|$9|15|A|16|B|C]|$9|17|A|18|B|C]]|D|@]|E|$]]|$1|N|3|O|5|6|7|19|8|@]|D|@]|E|$]]|$1|P|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]]|Q|$]]

Double-check that the parent-id is really 1. If not, and this is <code>firefox</code>, first try <code>sudo killall -9 firefox-bin</code>. After that, try killing the specific process IDs individually with <code>sudo killall -9 [process-id]</code>.

<blockquote>
 How is it even possible for a process not to listen to kill -9 (neiter as user nor as root)?
</blockquote>

If a process has gone <code>&lt;defunct&gt;</code> and then becomes a <a href="http://en.wikipedia.org/wiki/Zombie_process" rel="noreferrer">zombie</a> with a parent of 1, you can't kill it manually; only <code>init</code> can. Zombie processes are already dead and gone - they've lost the ability to be killed as they are no longer processes, only a process table entry and its associated exit code, waiting to be collected. You need to kill the parent, and you can't kill <code>init</code> for obvious reasons.

But see <a href="http://www.faqs.org/faqs/unix-faq/faq/part3/section-13.html" rel="noreferrer">here</a> for more general information. A reboot will kill everything, naturally.

blocks|key|346765|text|你也可以做一个pstree并杀死父母。这可以确保您得到整个违规进程树，而不仅仅是叶子。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|346766|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You can also do a pstree and kill the parent. This makes sure that you get the entire offending process tree and not just the leaf.

blocks|key|345913|text|有没有可能，这个进程在你杀死它的时候就被重新启动了(例如由init重启)？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|345914|您可以很容易地检查这一点。如果PID在kill+-9+PID之后是相同的，则该进程没有被终止，但是如果它发生了变化，则该进程已被重启。|offset|length|style|CODE|345915|entityMap^0|0|J|B|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Is it possible, that this process is restarted (for example by init) just at the time you kill it?

You can check this easily. If the PID is the same after <code>kill -9 PID</code> then the process wasn't killed, but if it has changed the process has been restarted.

blocks|key|3121844|text|正如在对OP的注释中所指出的，D的进程状态(STAT)指示进程处于“不可中断的睡眠”状态。在现实世界中，这通常意味着它在等待I/O，并且不能/不会做任何事情-包括死亡-直到I/O操作完成。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3121845|在操作完成并返回到R/S之前，处于D状态的进程通常只会在那里停留一小部分时间。根据我的经验，如果一个进程卡在D中，最常见的情况是它试图与无法访问的NFS或其他远程文件系统通信，试图访问出现故障的硬盘驱动器，或者通过不稳定的设备驱动程序使用某些硬件。在这种情况下，恢复并允许进程终止的唯一方法是重新启动和运行fs/驱动器/硬件，以便I/O可以完成，或者放弃并重新启动系统。在NFS的特定情况下，挂载也可能最终超时并从I/O操作返回(带有一个失败代码)，但这取决于挂载选项，NFS挂载通常被设置为永远等待。|3121846|这与僵尸进程不同，僵尸进程的状态将为Z。|3121847|entityMap^0|F|1|M|4|0|9|1|B|1|H|1|1I|1|0|I|1|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]|$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|Z|8|@$9|10|A|11|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|12|8|@]|D|@]|E|$]]]|K|$]]

As noted in comments to the OP, a process status (<code>STAT</code>) of <code>D</code> indicates that the process is in an "uninterruptible sleep" state. In real-world terms, this generally means that it's waiting on I/O and can't/won't do anything - including dying - until that I/O operation completes.

Processes in a <code>D</code> state will normally only be there for a fraction of a second before the operation completes and they return to <code>R</code>/<code>S</code>. In my experience, if a process gets stuck in <code>D</code>, it's most often trying to communicate with an unreachable NFS or other remote filesystem, trying to access a failing hard drive, or making use of some piece of hardware by way of a flaky device driver. In such cases, the only way to recover and allow the process to die is to either get the fs/drive/hardware back up and running so the I/O can complete or to give up and reboot the system. In the specific case of NFS, the mount may also eventually time out and return from the I/O operation (with a failure code), but this is dependent on the mount options and it's very common for NFS mounts to be set to wait forever.

This is distinct from a zombie process, which will have a status of <code>Z</code>.

blocks|key|3334767|text|最近，我陷入了Double+Fork的陷阱，在最终找到答案之前，我已经登录到了这个页面。即使问题不同，症状也是相同的：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3334768|3334769|WYKINWYT+:你杀死的不是你想的那样|unordered-list-item|3334770|3334771|下面是基于SNMP守护程序的示例显示的最小测试代码|3334772|#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+%25d\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");
}|code-block|syntax|javascript|3334773|在第一阶段，主进程(7699)启动SNMP守护进程(7700)，但我们可以看到这个守护进程现在已失效/僵尸。在旁边，我们可以看到具有我们指定的选项的另一个进程(7702|3334774|[nils@localhost+~]$+ps+-ef+%7C+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|3334775|在模拟的10秒后，我们将尝试杀死我们所知的唯一进程(7700)。我们最终使用waitpid()成功了。但是进程7702仍然在这里|3334776|[nils@localhost+~]$+ps+-ef+%7C+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|3334777|在为getchar()函数赋予一个字符之后，我们的主进程终止，但是pid为7002的SNMP守护进程仍然在这里|3334778|[nils@localhost+~]$+ps+-ef+%7C+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|3334779|结论|3334780|我们忽略了的double+fork机制，这让我们认为kill操作没有成功。但事实上，我们只是杀死了错误的进程！|style|BOLD|3334781|通过添加-f选项(+Do+Not+(Double)+Fork+)，所有操作均按预期进行|3334782|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/881388/what-is-the-reason-for-performing-a-double-fork-when-creating-a-daemon^0|7|B|0|0|0|0|0|0|0|0|0|0|0|0|0|0|5|C|0|4|2|0^^$0|@$1|2|3|4|5|6|7|1H|8|@]|9|@$A|1I|B|1J|1|1K]]|C|$]]|$1|D|3|-4|5|6|7|1L|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|1M|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|1N|8|@]|9|@]|C|$]]|$1|I|3|J|5|6|7|1O|8|@]|9|@]|C|$]]|$1|K|3|L|5|M|7|1P|8|@]|9|@]|C|$N|O]]|$1|P|3|Q|5|6|7|1Q|8|@]|9|@]|C|$]]|$1|R|3|S|5|M|7|1R|8|@]|9|@]|C|$N|O]]|$1|T|3|U|5|6|7|1S|8|@]|9|@]|C|$]]|$1|V|3|W|5|M|7|1T|8|@]|9|@]|C|$N|O]]|$1|X|3|Y|5|6|7|1U|8|@]|9|@]|C|$]]|$1|Z|3|10|5|M|7|1V|8|@]|9|@]|C|$N|O]]|$1|11|3|12|5|6|7|1W|8|@]|9|@]|C|$]]|$1|13|3|14|5|6|7|1X|8|@$A|1Y|B|1Z|15|16]]|9|@]|C|$]]|$1|17|3|18|5|6|7|20|8|@$A|21|B|22|15|16]]|9|@]|C|$]]|$1|19|3|-4|5|6|7|23|8|@]|9|@]|C|$]]]|1A|$1B|$5|1C|1D|1E|C|$1F|1G]]]]

I lately get trapped into a pitfall of <a href="https://stackoverflow.com/questions/881388/what-is-the-reason-for-performing-a-double-fork-when-creating-a-daemon">Double Fork</a> and had landed to this page before finally finding my answer. The symptoms are identical even if the problem is not the same:

<ul>
<li>WYKINWYT :What You Kill Is Not What You Thought</li>
</ul>

The minimal test code is shown below based on an example for an SNMP Daemon

<pre class="lang-cpp prettyprint-override"><code>#include &lt;unistd.h&gt;
#include &lt;stdio.h&gt;
#include &lt;stdlib.h&gt;
#include &lt;signal.h&gt;

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 &gt; 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");
}
</code></pre>

During the first phase the main process (7699) launches the SNMP daemon (7700) but we can see that this one is now Defunct/Zombie. Beside we can see another process (7702) with the options we specified

<pre><code>[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] &lt;defunct&gt;
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
</code></pre>

After the 10 sec simulated we will try to kill the only process we know (7700). What we succeed at last with waitpid(). But Process 7702 is still here

<pre><code>[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
</code></pre>

After giving a character to the getchar() function our main process terminates but the SNMP daemon with the pid 7002 is still here

<pre><code>[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
</code></pre>

Conclusion

The fact that we ignored the double fork mechanism made us think that the kill action did not succeed. But in fact we simply killed the wrong process !!

By adding the -f option ( Do Not (Double) Fork ) all go as expected

I'm writing a plugin to highlight text strings automatically as you visit a web site. It's like the highlight search results but automatic and for many words; it could be used for people with allergies to make words really stand out, for example, when they browse a food site.

But I have problem. When I try to close an empty, fresh FF window, it somehow blocks the whole process. When I kill the process, all the windows vanish, but the Firefox process stays alive (parent PID is 1, doesn't listen to any signals, has lots of resources open, still eats CPU, but won't budge).

So two questions:

<ol>
<li>How is it even possible for a process not to listen to kill -9 (neither as user nor as root)?</li>
<li>Is there anything I can do but a reboot?</li>
</ol>

[EDIT] This is the offending process:

<pre><code>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
</code></pre>

Same with <code>ps -ef | grep firefox</code>

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

It's the only process left. As you can see, it's not a zombie, it's running! It doesn't listen to kill -9, no matter if I kill by PID or name! If I try to connect with <code>strace</code>, then the <code>strace</code> also hangs and can't be killed. There is no output, either. My guess is that FF hangs in some kernel routine but which?

[EDIT2] Based on feedback by sigjuice: 

<pre><code>ps axopid,comm,wchan
</code></pre>

can show you in which kernel routine a process hangs. In my case, the offending plugin was the Beagle Indexer (openSUSE 11.1). After disabling the plugin, FF was a quick and happy fox again.

How is it possible that kill -9 for a process on Linux has no effect?

设备驱动程序

文件系统

openSUSE

我正在写一个插件，当你访问网站时，它会自动突出显示文本字符串。它类似于突出显示的搜索结果，但它是自动的，可以用于许多单词；它可以用于有过敏症的人，例如，当他们浏览食物网站时，使单词真正突出。但我有个问题。当我试图关闭一个空的、新鲜的FF窗口时，它以某种方式阻塞了整个过程。当我杀死这个进程时，所有的窗口都消失了，但是Fi...

问对于Linux上的进程，kill -9怎么可能没有影响呢？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问对于Linux上的进程，kill -9怎么可能没有影响呢？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问对于Linux上的进程，kill -9怎么可能没有影响呢？
EN