问题描述
我正在努力提高我的命令行技能，并且遇到了无法杀死进程的问题。我键入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
最佳解决办法
进程可以忽略一些信号。如果您发送SIGKILL，它将无法忽略它(并且无法捕捉它进行清理)。尝试：
kill -9 {PID}
通过阅读手册页了解更多信息：
man kill
次佳解决办法
如果kill没有任何参数被调用，它将发送信号编号15(SIGTERM)。该信号可以被该过程忽略。这个信号通知过程清理他的东西，然后自己正确地结束。这是很好的方式。
您也可以在”send”中输入信号编号9(SIGKILL)，该过程不能忽略。该进程甚至不会识别它，因为内核结束了进程，而不是进程本身。这是邪恶的方式。
有人说kill -9 <pid>总是有效。这是一个错误的信念。有些情况下，即使kill -9也不会终止进程。例如，当进程具有状态D(不间断睡眠)时。每当它等待I /O(通常不是很长)时，进程就会进入这种状态。所以，如果一个进程等待I /O(例如在一个缺陷硬盘上)并且没有正确编程(有超时)，那么你根本无法终止进程。无论你做什么。您可以尝试使该文件可以访问该进程继续。
第三种解决办法
尽管它的名称kill并不实际上终止进程，但它会向它发送信号。从手册页：
kill - send a signal to a process
kill [pid]发送的默认信号是SIGTERM，通常但不一定要求进程终止。当你发送SIGTERM信号给它时，编写一个播放快乐曲子的程序是很有可能的，但不推荐。
另一个常见信号是SIGHUP，它经常用于请求程序重新读取其配置文件。
如果你真的想杀死一个程序，你需要通过kill -9 [pid]来使用SIGKILL信号。
第四种办法
这听起来像你可能会暂停一个进程(可能通过在终端中按Ctrl-Z)。在这种状态下，您的进程在冻结时不会对SIGTERM做出响应。运行’fg’解冻过程，因此它可以拾取信号和self-terminate。这可以解释为什么’fg’似乎更新进程列表。