☰

`[java]` 与已去世的孩子 -> 有什么方法可以收集它们吗？

tag-icon • tag-icon process kill process-management init thread
`[java]` 与已去世的孩子 -> 有什么方法可以收集它们吗？

与问题相关：如果“kill -9”不起作用怎么办？

我有以下情况：有线程的僵尸进程，不被 init 收集:

[root@Arch64]# ps auxH | grep java
gwpl       569  0.0  0.0      0     0 ?        Zl   04:23   0:00 [java] <defunct>
gwpl       569  5.5 49.0 1466648 375572 ?      Rl   07:25  23:55 [java] <defunct>
gwpl       569 16.0 49.0 1466648 375572 ?      Rl   12:27  20:54 [java] <defunct>
gwpl       569 17.9 49.0 1466648 375572 ?      Rl   12:47  19:48 [java] <defunct>
root     10466  0.0  0.0   6740   628 pts/0    S+   14:38   0:00 grep java
[root@Arch64]# pstree -s 569
init---java---3*[{java}]

我能做点什么吗？

或者是在里面评论中建议的错误https://unix.stackexchange.com/a/11173/9689？

如果这是一个错误，我应该转储什么来帮助修复它？

上面的列表使用以下状态代码：Zl、Rl、S+。这是man ps解码它们的备忘单：

PROCESS STATE CODES
       (...)
       R    Running or runnable (on run queue)
       S    Interruptible sleep (waiting for an event to complete)
       (...)
       Z    Defunct ("zombie") process, terminated but not reaped by its parent.

       For BSD formats and when the stat keyword is used, additional characters may be displayed:
       (...)
       L    has pages locked into memory (for real-time and custom IO)
       (...)
       +    is in the foreground process group

答案1

这可能已经太晚了，没有任何好处，但我想知道是否可能是进程 569不是完全是僵尸。也许这就是当初始线程已终止但其他线程仍在运行时您在该操作系统（哪个操作系统是？）上得到的结果。如果是这样的话，kill(1)应该还是有效的。如果不是，我接下来要尝试的是使用tgkill(2)，或您的操作系统的等效项，在 R 状态中列出的线程上（这将需要您编写一些 C，因为可能没有预装的 shell 实用程序来调用这些系统调用）。

此外，尝试附加strace或gdb附加到该过程可能会揭示一些对诊断有用的信息。

收割僵尸时出现错误的init可能性极小；如果这是一个错误，我会说它更有可能是一个核心多线程进程（在某些情况下）未正确处理的错误。

答案2

Init总是等待，俗话说。因此内核中出现错误的可能性很小。进程569的ppid是多少？ps -alef会给你这个，或者，如果你有 BSD 观点，ps axo stat,pid.ppid,comm .如果父进程不是 init，569 可能是一个普通的僵尸。由于僵尸只有在数量较多时才会变得危险，因此您可以将其放在角落里，并在下次重新启动时将其处理掉。

相关内容