“kill <PID>”并没有真正杀死进程，为什么？

Question

我正在尝试提高我的命令行技能，但遇到了无法终止进程的问题。我输入kill 2200其中 2200 是我的 PID 并且进程没有被终止。几分钟后等待仍然在top和ps aux。我什至尝试用 sudo 输入它 - 没有结果。

任何想法为什么会这样？

---

编辑

我发现了一个奇怪的依赖项，其中fg更新了进程列表：

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2200 pts/0    00:00:00 top
 2202 pts/0    00:00:00 top
 2258 pts/0    00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2200 pts/0    00:00:00 top
 2620 pts/0    00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2621 pts/0    00:00:00 ps

Answer 1

进程可以忽略一些信号。如果您发送 SIGKILL 它将无法忽略它（也不能捕获它进行清理）。尝试：

kill -9 {PID}

通过阅读手册页了解更多信息：

man kill

Answer 2

如果kill不带任何参数调用，则发送信号编号 15 ( SIGTERM)。该信号可以被进程忽略。该信号通知进程清理他的东西，然后由他自己正确结束。这是很好的方式。

您还可以“发送”SIGKILL进程无法忽略的信号编号 9 ( )。进程甚至不会识别它，因为内核结束了进程，而不是进程本身。那是邪恶的方式。

有人说kill -9 <pid>总是有效。那是一种误解。有些情况甚至kill -9不会终止进程。例如，当进程具有状态D（不可中断睡眠）时。进程每次等待 I/O 时都会进入此状态（通常不会很长）。因此，如果一个进程等待 I/O（例如在有缺陷的硬盘上）并且它没有正确编程（超时），那么您根本无法终止该进程。无论你做什么。您可以尝试使该文件可访问，该过程继续进行。

Answer 3

尽管它的名字 kill 实际上并没有杀死进程，但它会向它发送信号。从手册页：

kill - send a signal to a process

发送的默认信号kill [pid]是SIGTERM，它通常但不一定要求进程终止。当您向它发送SIGTERM信号时，编写一个播放愉快曲调的程序是很有可能的，但不推荐。

另一个常见的信号是SIGHUP，它通常用于要求程序重新读取其配置文件。

如果你真的想杀死一个程序，你需要通过执行SIGKILL信号kill -9 [pid]。