一次 Docker 容器内大量僵尸进程排查分析

前段时间线上的一个使用 Google Puppeteer 生成图片的服务炸了，每个 docker容器内都有几千个孤儿僵死进程没有回收，如下图所示。

这篇文章比较长，主要就讲了下面这几个问题。

• 什么情况下会出现僵尸进程、孤儿进程
• Puppeteer 工作过程启动的进程与线上事故分析
• PID 为 1 的进程有什么特殊的地方
• 为什么 node/npm 不应该作为镜像中 PID 为 1 的进程
• 为什么 Bash 可以作为 PID 为 1 的进程，以及它做 PID 为 1 的进程有什么缺陷
• 镜像中比较推荐的 init 进程的做法是什么

Puppeteer 是一个 node 库，是 Chrome 官方提供的无界面 chrome 工具(headless chrome)，它提供了操作ChromeAPI 的方式，允许开发者在程序中启动 chrome 进程，调用 JS 的 API 实现页面加载、数据爬取、web 自动化测试等功能。

本案例中使用的场景是使用 Puppeteer 加载 html，随后截图生成一张分销海报的图片。文章分析了这个问题背后的原因，接下来开始正式的内容。

进程

每个进程都有一个唯一的标识，称为 pid，pid 是一个非负的整数值，使用 ps 命令可以查看，在我的 Mac 电脑上执行 ps-ef可以看到当前运行的所有进程，如下所示。

其中 PID 是表示进程号。

系统中每个进程都有对应的父进程，上面 ps 输出中的 PPID 就表示进程的父进程号。最顶层的进程的 PID 为 1，PPID 为 0。

打开 iTerm，在终端中执行一个命令，比如 "ls"，实际上系统会创建新的 iTerm 子进程，这个 iTerm 进程又创建了 zsh 子进程。在zsh中输入的 ls 命令，则是 zsh 进程又启动了一个 ls 子进程。在 iTerm 中输入 ls 命令过程的进程关系如下所示。

进程与 fork

前面提到的父进程“创建”子进程，更严谨的描述是 fork(孵化、衍生)。下面来看一个实际的例子，新建一个 fork_demo.c 文件。

执行上的代码，会输出如下的语句。

可以看到 if、else 语句都被执行了。

fork 调用

fork 是一个系统调用，它的方法声明如下所示。

fork 调用完成后会生成一个新的子进程，且父子进程都从 fork 返回处继续执行。这里需要特别注意的是fork的返回值的含义，在父进程和新的子进程中，它们的含义不一样。

• 在父进程中 fork 的返回值是新创建的子进程 id
• 在创建的子进程中 fork 的返回值始终等于 0

因此可以通过 fork 的返回值区分父子进程，在运行过程中可以使用 getpid 方法获取当前的进程 id。fork 典型的使用方式如下所示。

执行上面的代码，输出结果如下所示。

子进程是父进程的副本，子进程拥有父进程数据空间、堆、栈的复制副本 ，fork 采用了 copy-on-write技术，fork操作几乎瞬间可以完成。只有在子进程修改了相应的区域才会进行真正的拷贝。

孤儿进程：不能同年同月同日生，也不会同年同月同日死

接下来问一个问题，父进程挂掉时，子进程会挂掉吗?

想象现实中的场景，父亲不在了，儿子还可以活吗?答案是肯定的。对应于进程，父进程退出时，子进程会继续运行，不会一起共赴黄泉。

一个父进程已经终止的进程被称为孤儿进程(orphan process)。操作系统这个大家长是比较人性化的，没有人管的孤儿进程会被进程 ID 为1的进程接管。这个 PID 为 1 的进程后面还会再讲到。

接下来对之前的代码稍作修改，让父进程 fork 子进程以后自杀退出，生成孤儿进程。代码如下所示。

编译运行上面的代码

输出结果如下。

可以看到父进程 id 为 21629， 生成的子进程 id 为 21630。

使用 ps 查看当前进程信息，结果如下所示。

可以看到此时孤儿子进程 21630 的父 ID 已经变为了顶层的 ID 为 1 的进程。

僵尸进程

父进程负责生，如果不负责养，那就不是一个好父亲。子进程挂了，如果父进程不给子进程“收尸”(调用wait/waitpid)，那这个子进程小可怜就变成了僵尸进程。

新建一个 make_zombie.c 文件，内容如下。

编译运行上面的代码，就可以生成一个进程号为 22538 的僵尸进程，如下所示。

CMD 名中的 defunct 表示这是一个僵尸进程。

也使用 ps 命令查看进程的状态，显示为 "Z" 或者 "Z+" 表示这是一个僵尸进程，如下所示。

子进程退出后绝大部分资源已经被释放可供其他进使用，但是内核的进程表中的槽位没有释放。

僵尸进程有一个很神奇的特性，使用 kill -9必杀信号都没有办法杀掉僵尸进程，这样的设计利弊参半，好的地方是父进程可以总是有机会执行wait/waitpid等命令收割子进程，坏的地方是无法强制回收这种僵尸进程。

PID 为 1 的进程

Linux 中内核初始化以后会启动系统的第一个进程，PID 为 1，也可以称之为 init 进程或者根(ROOT)进程。在我的 Centos机器上，这个init 进程是 systemd，如下所示。

在我的 Mac 电脑上，这个进程为 launchd，如下所示。

init 进程有下面这几个功能

• 如果一个进程的父进程退出了，那么这个 init 进程便会接管这个孤儿进程。
• 如果一个进程的父进程未执行 wait/waitpid 就退出了，init 进程会接管子进程并自动调用 wait方法，从而保证系统中的僵尸进程可以被移除。
• 传递信号给子进程，这点后面会介绍。

为什么 Node.js 不适合做 Docker 镜像中 PID 为 1 的进程

在 Node.js 的官方最佳实践里有写到 "Node.js was not designed to run as PID 1 which leadstounexpected behaviour when running inside ofDocker."。下图来自github.com/nodejs/dock… 。

接下来会做两个实验：第一个实验是在 Centos 机器上，第二个实验是在 Docker 镜像中

实验一：在 Centos 上，systemd 作为 PID 为 1 的进程

下面来做一些测试，修改上面的代码，将父进程 sleep 的时间改短为 15s，新建一个 make_zombie.c 文件，如下所示。

编译生成可执行文件 make_zombie。

然后新建一个 run.js 代码，内部启动一个进程运行 make_zombie，如下所示。

执行 node run.js 运行这段 js 代码，使用 ps -ef 查看进程关系如下。

过 15s 以后，再次执行 ps -ef 查询当前运行的进程，可以看到 make_zombie 相关进程都不见了。

这是因为 PID 为 29519 的 make_zombie 父进程在 15s 以后退出，僵尸子进程被托管到 init进程，这个进程会调用wait/waitfor 为这个僵尸收尸。

实验二：在 Docker 上，node 作为 PID 为 1 的进程

将 make_zombie 可执行文件和 run.js 打包为 .tar.gz 包，随后新建一个 Dockerfile，内容如下。

执行 docker build 命令构建一个镜像，在我的电脑上 Image ID 为 ab71925b5154， 执行 dockerrunab71925b5154，启动 docker 镜像，使用 docker ps 找到镜像 CONTAINER ID，这里为e37f7e3c2e39。随即使用docker exec 进入到镜像终端

执行 ps 命令查看当前的进程状况，如下所示。

等一段时间(15s)，再次执行 ps 查看当前进程，如下所示。

可以看到 PID 为 13 的僵尸进程已经托管到 PID 为 1 的 node 进程，但是没有被回收。

这是 node 不适合做 init 进程的最主要原因：无法回收僵尸进程。

说到 node，这里提一下 npm，npm 实际上是使用 npm 进程启动了一个子进程启动了 package.json 中scripts里写的启动脚本，示例 package.json 脚本如下所示。

使用 npm run start 启动，得到的进程如下所示。

与 node 一样，npm 也不会处理僵尸子进程回收。

线上问题分析

我们线上出问题的情况下使用 npm start 来启动一个 Puppeteer 项目，每生成一次图片便会创建 4 个 chrome相关的进程，如下所示。

在图片生成完成时，chrome 主进程退出，剩下的三个孤儿僵尸进程被托管到顶层 npm 进程下，但是npm进程无力回收，所有每生成一次图片便会新增三个僵尸进程。在成千上万次图片生成以后，系统中就充满了僵尸进程。

解决办法

为了解决这个问题，不能让 node/npm 成为 init 进程，让有能力接管僵尸进程的服务成为 init 进程即可，有两个解决办法。

• 使用 bash 启动 node 或者 npm
• 增加专门的 init 进程，比如 tini

解决方式一：使用 bash 启动 node

让 bash 成为顶层进程是比较快的一种方式，bash 进程会负责回收僵尸进程，修改 Dockerfile，如下所示。

使用这种方式是比较简单，而且之前线上没有出问题正是因为一开始是使用这种 bash 方式启动 node，后面有一个小兄弟为了统一启动命令将这个命令改为npmrun start，问题才出现的。

但使用 bash 并非完美的方案，它有一个比较严重的问题，bash 不会传递信号给它启动的进程，优雅停机等功能无法实现。

接下来做一个实验，验证 bash 不会传递信号给子进程的说法，新建一个 signal_test.c文件，它处理SIGQUIT、SIGTERM、SIGTERM 三个信号，内容如下。

在我 Centos 和 Mac 上运行这个 signal_test 程序时，发送 kill-2、-3、-15给这个程序，都会有对应的打印输出，表示收到了信号。如下所示。

在 Docker 镜像中使用 bash 启动这个程序时，发送 kill 命令给 bash 以后，bash 并不会将信号传递给signal_test程序。在执行 docker stop 以后，docker 会发送 SIGTERM(15) 信号给bash，bash并不会将这个信号传递给启动的应用程序，只能等一段时间超时，docker 会发送 kill -9 强制杀死这个docker进程，无法达到优雅停机的功能。

于是有了下面的第二种解决方案。

解决方式二：使用专门的 init 进程

Node.js 提供了两种方案，第一种是使用 docker 官方的轻量级 init 系统，如下所示。

这种启动方式会以 /sbin/docker-init 为 PID 为 1 的 init 进程，不会把 Dockerfile 中 CMD作为第一个启动进程。

以下面的 Dockerfile 内容为例

执行 docker run -it --init image_id 启动 docker 镜像，此时镜像内的进程如下所示。

可以看到 signal_test 程序作为 docker-init 的子进程启动了。

在 docker stop 命令发送 SIGTERM 信号给镜像以后，docker-init进程会将这个信号转给signal_test，这个应用进程就可以收到 SIGTERM 信号做自定义的处理，比如优雅停机等。

除了 docker 的官方方案，Node.js 的最佳实践还推荐了一个 tini 这样一个 C 语言写的极小的init进程，github.com/krallin/tin… 。它的代码较短，很值得一读，对理解信号传递、处理僵尸进程非常有帮助。

小结

通过这篇文章，希望你可以搞懂僵尸进程、孤儿进程、PID 为 1 的进程是什么，以及为什么 node/npm 不适合做 PID 为 1 的进程，bash作为PID 为 1 的进程有什么缺陷。

下面留一个作业题，考考你对进程 fork 函数的理解。如下程序连续调用三次 fork() 调用后会产生多少新进程?