进程无法杀死是什么原因, Running 状态的

[plko345]

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

[plko345]

忘记说了, 是 ubuntu 16.04 64bit

[wellsc]

孤儿进程

[pkokp8]

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

[choury]

cat /proc/xxx/stack

[weyou]

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

[plko345]

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

[wunonglin]

@wellsc 哈哈哈哈哈哈哈哈哈哈哈哈 h'h'h'h

[a663]

进程是 D 状态了吧？

[plko345]

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

[plko345]

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

[mango88]

@wellsc 优秀

[wellsc]

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

[yuikns]

linux 里面的 signal 体系都是接收者处理的。你发送 sigkill 后，目标进程在收到 sig 后自行了断。

没有反应有两种可能，一种是程序自定义了 sigkill 的行为，一种是 cpu 一直在忙，可能死循环了。

前者把同事撸起来打一顿重启服务器，后者你试试等两天看它会不会消失，有时候会，不然重启服务器吧

[zorn]

有守护进程？

[yuikns]

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

[yuikns]

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

[wwqgtxx]

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

[yuikns]

@wwqgtxx 感谢指教

https://en.wikipedia.org/wiki/Signal_(IPC)#SIGKILL

> 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 不成功，但是有其它程序在跑又不太好直接重启。于是就等上两天，它自己抽出空就能消失。

[linbiaye]

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

[aa514758835]

杀他父亲 进程