• 开发的机器上有人跑了个 python 任务, 他没有把任务跑在后台
• 然后 ssh 连接断开, 但这程序并没有终止
• 他是用他自己的用户起的, 没有使用 sudo
• 我用 root 用户 kill -9 就是毫无反应
• strace 也没有追踪不到这个进程的任何信息
• 父进程是 1

忘记说了, 是 ubuntu 16.04 64bit

孤儿进程

是不是进入了某些系统中断，所以你无法 kill

cat /proc/xxx/stack

进程被 system call 阻塞了，除此之外还没见过-9 kill 不掉的处于 running 状态的用户进程。

这个我看过, 但没发现什么信息, 可以指点下吗?

哈哈哈哈哈哈哈哈哈哈哈哈 h'h'h'h

进程是 D 状态了吧？

是 R 状态, 这才是我觉得诡异的地方

而且进程吃了一个 CPU 核心的资源

优秀

笑啥。。我有说错什么了么？

linux 里面的 signal 体系都是接收者处理的。你发送 sigkill 后，目标进程在收到 sig 后自行了断。
没有反应有两种可能，一种是程序自定义了 sigkill 的行为，一种是 cpu 一直在忙，可能死循环了。
前者把同事撸起来打一顿重启服务器，后者你试试等两天看它会不会消失，有时候会，不然重启服务器吧

有守护进程？

python 的线程稀烂，结果各种库都使用多进程。弄到现在搞成这样也是常见

可能是多进程，挂起后子进程变孤儿

我记得按照 Linux 规范，程序并不允许自己处理 SIGKILL 信号，内核会直接接管，你说的收到 sig 自行了断的是 SIGTREM

感谢指教
https://en.wikipedia.org/wiki/Signal_(IPC)In contrast to SIGTERM and SIGINT, this signal cannot be caught or ignored
学习了。稍微程序试了下，的确不行。平时做 gracefully shutdown 特意只屏蔽了 SIGHUP, SIGINT, SIGTERM 和 SIGQUIT 就想留着 SIGKILL 给脸着地用的。没想到其实也不被允许这样做。
因此我第一种猜想显然是脑补错误的。
关于 “自行了断”，应该是我表述问题。我记得&理解是这样的。通常情况下，所有信号是异步的，我们发送 sigkill, kernel 把它丢进了 q，然后对应进程结束回收资源。通常情况下，它会在若干时间片里面就处理完毕。但是例外也是有的。普通的用户进程是可以随便打断的，但是涉及到 kernel 的调用有时候不行。如果有些 kernel 级别的调用在很短周期内反复使用，或者一直调用不成功，抽不出时间片处理信号，目标的回收就会被延时。
以前有时候遇到有些 python 用户，挂了 100 多 G 数据在内存，意外死了。执行 kill 不成功，但是有其它程序在跑又不太好直接重启。于是就等上两天，它自己抽出空就能消失。

sigkill 这个信号 os 是会直接杀死进程，而不是通知进程。进程如果 D 住了则无效，楼主这个更像是遇到 BUG。

杀他父亲 进程

1 哈哈哈哈哈哈哈哈哈哈哈哈。一个 run 状态的，非 root 用户启动的，进程，kill -9 杀不死。
哈哈哈哈哈哈哈哈哈哈哈哈。应该存在么？我认为不应该。
这样的一个 win 进程，应该存在吗？我认为不应该。
2 如何解决：
除非内存耗尽了，但一般不可能。
vmstat 看看。等半小时还没 kill -9 掉，就应该重启机子，若暂时不能重启，就等空闲重启。
3 为什么：
内核 bug，或 glibc 等 bug。所以你要升级 linux 发行版到 ubuntu 16.04.6，并升级内核到最新。
4 若还能重现问题。那就是这个 linux 太垃圾！
就只能不用这种 linux。或者直接修改源码，直接找厂家。
5 上面的观点 4，有人不同意么？
普通用户可以运行 1024 个进程，
不用 1024，几个流氓 py 进程，坐在你 linux 家里大吃二喝不给钱，怎么弄也不走，
你找来警察，警察 kill 来了也不灵。
很容易就可以把你的 linux 家 “塞满，涨死”，对不？
你只能找盖 linux 房子的创世神，毁灭房子。彻底重设计 。
不重设计，只是重盖，刚盖好，流氓又钻进来“坐吃”了。

就是 root 启动的进程，就算是进入了某些中断，也应该能 kill -9 掉！
另外，是否还有人认为，linux 可以 n 年不补丁？不用重启？

即有可能是一个 service,而且是自动重启的那种。