“杀死”并没有真正杀死这个过程，为什么？
我正在努力提高我的命令行技能，我遇到了一个无法杀死进程的问题。 我键入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 ）。 该过程可以忽略该信号。 该信号通知过程清理他的东西，然后由他自己正确结束。 这是很好的方式。
您还可以“发送”进程不能忽略的信号9（ SIGKILL ）。 该过程甚至无法识别它，因为内核结束了进程，而不是进程本身。 这是邪恶的方式。
有人说kill -9 总能奏效。 这是一种误解 。 有些情况下甚至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’解冻过程，因此它可以接收信号并自行终止。 这可以解释为什么’fg’似乎更新了进程列表。
在C ++中，我执行了：
kill(4024, SIGKILL);
在Linux（Ubuntu）终端上，
$ ps -ax | grep my_su
输出是：
4024 pts/1 Z+ 0:00 [my_subscriber]
看起来，它（4024）仍然幸存。 但是，一旦我终止调用上述“kill”语句的父进程，4024就不再出现了。 现在我判断“失效”过程只不过是显示的一行，并决定忽略它。 我希望我的经历可以帮助那里的人。 干杯!