持续存在的僵尸进程是错误的迹象吗？

Question 1

看到僵尸往往表明产生它们的进程中存在错误：该进程应该收获僵尸（通过调用wait）或显式忽略SIGCLD（或设置SA_NOCLDWAIT标志）。

然而，这是一个小错误。僵尸进程仅消耗进程表中的一个条目，这是可以忽略不计的资源量。只有当一个进程留下数千个僵尸时，问题才会变得严重。

你还没有杀死僵尸的父进程：否则僵尸就会消失。进程 29673（僵尸进程的父进程）仍然活着并且正在运行（但没有wait运行）。这要么不是 Gvim，而是它的某个子进程，要么您关闭了 Gvim 窗口但程序仍在运行。运行ps l 29673看看这个进程是什么。

Answer

看到僵尸往往表明产生它们的进程中存在错误：该进程应该收获僵尸（通过调用wait）或显式忽略SIGCLD（或设置SA_NOCLDWAIT标志）。

然而，这是一个小错误。僵尸进程仅消耗进程表中的一个条目，这是可以忽略不计的资源量。只有当一个进程留下数千个僵尸时，问题才会变得严重。

你还没有杀死僵尸的父进程：否则僵尸就会消失。进程 29673（僵尸进程的父进程）仍然活着并且正在运行（但没有wait运行）。这要么不是 Gvim，而是它的某个子进程，要么您关闭了 Gvim 窗口但程序仍在运行。运行ps l 29673看看这个进程是什么。

Question 2

如果您不断遇到僵尸进程，我会倾向于认为肯定有问题。僵尸进程确实会发生。我通常每个月都会在工作和家里维护的各种系统上看到几次。

通常，它们可以归因于操作员错误或特定软件的问题。重新启动通常可以解决这些问题，并且通常在一段时间内不会再次出现。

如果它们给你带来麻烦，你可以尝试附加到它们的父进程 ID (PPID)，以gdb查看发生了什么，甚至尝试杀死它们：

$ gdb -p 100
(gdb) call waitpid(200, 0, 0)
(gdb) quit

如果您愿意的话，我会阅读下面的这些附加资源，以了解尝试处理它们的其他技术。

参考

Answer

如果您不断遇到僵尸进程，我会倾向于认为肯定有问题。僵尸进程确实会发生。我通常每个月都会在工作和家里维护的各种系统上看到几次。

通常，它们可以归因于操作员错误或特定软件的问题。重新启动通常可以解决这些问题，并且通常在一段时间内不会再次出现。

如果它们给你带来麻烦，你可以尝试附加到它们的父进程 ID (PPID)，以gdb查看发生了什么，甚至尝试杀死它们：

$ gdb -p 100
(gdb) call waitpid(200, 0, 0)
(gdb) quit

如果您愿意的话，我会阅读下面的这些附加资源，以了解尝试处理它们的其他技术。

参考

Question 3

每次使用gvim都会出现这种情况吗？ gvim 除了退出后留下僵尸之外还可以工作吗？除非它引起真正的问题，否则我会简单地忽略它 - 僵尸不会占用系统资源。如果这是 gvim 中的错误，或者可能是 gtk 中的错误，我不会感到惊讶，但除非该程序根本无法工作，否则我会忽略它。

当子进程在父进程开始监听它之前退出时，通常会发生僵尸/失效进程。孩子“坚持”，因为周围没有程序来接收它的退出状态，即使它确实令人满意地终止了 - 因此它变成了僵尸。僵尸的另一个原因可能是当一个大的进程树倒塌时 - 也许是因为有人试图杀死树中的一个或多个进程。

僵尸实际上是操作系统保留退出状态和有关未正确终止的进程的其他信息的一种方式，以防有人感兴趣。除了进程表中的条目外，僵尸进程不占用任何资源（即不占用内存或 CPU）。

恕我直言，维基百科是错误的 - 或者至少很容易误解 - 当它声称未收割的僵尸意味着操作系统的错误，如果它们在退出产生的主进程之后徘徊。僵尸在父母死后幸存下来的情况并不罕见，在这种情况下，它会被init（PID 1）收养。 init可能最终会收获它，但一些僵尸——甚至是那些被 init 采用的僵尸——很可能会一直保留到重新启动为止。只要僵尸进程没有太多以至于填满了进程表，它们就几乎不成问题。

当然，僵尸通常意味着出现了问题 - 程序生成了一个子程序，该子程序在父程序预期之前死亡 - 但问题不一定是操作系统。当然，这可能是操作系统组件造成的 - 例如。声音服务器丢失或配置错误，会导致应该为程序处理声音的子进程立即退出，从而像僵尸一样留下来。

Answer

每次使用gvim都会出现这种情况吗？ gvim 除了退出后留下僵尸之外还可以工作吗？除非它引起真正的问题，否则我会简单地忽略它 - 僵尸不会占用系统资源。如果这是 gvim 中的错误，或者可能是 gtk 中的错误，我不会感到惊讶，但除非该程序根本无法工作，否则我会忽略它。

当子进程在父进程开始监听它之前退出时，通常会发生僵尸/失效进程。孩子“坚持”，因为周围没有程序来接收它的退出状态，即使它确实令人满意地终止了 - 因此它变成了僵尸。僵尸的另一个原因可能是当一个大的进程树倒塌时 - 也许是因为有人试图杀死树中的一个或多个进程。

僵尸实际上是操作系统保留退出状态和有关未正确终止的进程的其他信息的一种方式，以防有人感兴趣。除了进程表中的条目外，僵尸进程不占用任何资源（即不占用内存或 CPU）。

恕我直言，维基百科是错误的 - 或者至少很容易误解 - 当它声称未收割的僵尸意味着操作系统的错误，如果它们在退出产生的主进程之后徘徊。僵尸在父母死后幸存下来的情况并不罕见，在这种情况下，它会被init（PID 1）收养。 init可能最终会收获它，但一些僵尸——甚至是那些被 init 采用的僵尸——很可能会一直保留到重新启动为止。只要僵尸进程没有太多以至于填满了进程表，它们就几乎不成问题。

当然，僵尸通常意味着出现了问题 - 程序生成了一个子程序，该子程序在父程序预期之前死亡 - 但问题不一定是操作系统。当然，这可能是操作系统组件造成的 - 例如。声音服务器丢失或配置错误，会导致应该为程序处理声音的子进程立即退出，从而像僵尸一样留下来。

Question 4

一如既往 - 这取决于。如果大多数监控工具遇到超过一定数量的僵尸进程，它们就会变成黄色或红色。

所以基本上 - 是的 - 这通常是问题的征兆。

但我见过一些程序会产生僵尸进程作为其“正常”操作的一部分。当使用“quit/exit”命令调用相应的顶级 api（这里我不说父进程）时，这些僵尸进程就消失了。

因此，在这些情况下，应用程序似乎照顾（并且可能需要）这些僵尸。因此，为了进行监控，我必须在运行这些应用程序的服务器上定义一个异常。

在其他情况下，僵尸进程会在短时间内消失 - 因此僵尸进程可能具有某些非持久系统状态。

在你的情况下：如果gvim完成了，应该不会剩下僵尸 - 所以可能是一个错误。

Answer