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

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

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

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

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

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

进程

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

UID   PID  PPID   C STIME   TTY           TIME CMD  0     1     0   0 六04下午 ??        23:09.18 /sbin/launchd  0    39     1   0 六04下午 ??         0:49.66 /usr/sbin/syslogd  0    40     1   0 六04下午 ??         0:13.00 /usr/libexec/UserEventAgent (System)

其中 PID 是表示进程号。

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

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

  UID   PID  PPID   C STIME   TTY           TIME CMD  501   321     1   0 六04下午 ??        61:01.45 /Applications/iTerm.app/Contents/MacOS/iTerm2 -psn_0_81940  501 97920   321   0  8:02上午 ttys039    0:00.07 /Applications/iTerm.app/Contents/MacOS/iTerm2 --server login -fp arthur    0 97921 97920   0  8:02上午 ttys039    0:00.03 login -fp arthur  501 97922 97921   0  8:02上午 ttys039    0:00.29 -zsh  501 98369 97922   0  8:14上午 ttys039    0:00.00 ./a.out

进程与 fork

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

#include #include int main() {  int ret = fork();  if (ret) {    printf("enter if block/n");  } else {    printf("enter else block/n");  }  return 0;}

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

enter if blockenter else block

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

fork 调用

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

pid_t fork(void);

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

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

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

#include #include #include int main() {  printf("before fork, pid=%d/n", getpid());  pid_t childPid;  switch (childPid = fork()) {    case -1: {      // fork 失败      printf("fork error, %d/n", getpid());      exit(1);    }    case 0: {      // 子进程代码进入到这里      printf("in child process, pid=%d/n", getpid());      break;    }    default: {      // 父进程代码进入到这里      printf("in parent process, pid=%d, child pid=%d/n", getpid(), childPid);      break;    }  }  return 0;}

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

before fork, pid=26070in parent process, pid=26070, child pid=26071in child process, pid=26071

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

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

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

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

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

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

#include #include #include int main() {  printf("before fork, pid=%d/n", getpid());  pid_t childPid;  switch (childPid = fork()) {    case -1: {      printf("fork error, %d/n", getpid());      exit(1);    }    case 0: {      printf("in child process, pid=%d/n", getpid());      sleep(100000); // 子进程 sleep 不退出      break;    }    default: {      printf("in parent process, pid=%d, child pid=%d/n", getpid(), childPid);      exit(0); // 父进程退出    }  }  return 0;}

编译运行上面的代码

gcc fork_demo.c -o fork_demo; ./fork_demo

输出结果如下。

before fork, pid=21629in parent process, pid=21629, child pid=21630in child process, pid=21630

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

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

UID        PID  PPID  C STIME TTY          TIME CMDroot         1     0  0 12月12 ?      00:00:53 /usr/lib/systemd/systemd --system --deserialize 21ya       21630     1  0 19:26 pts/8    00:00:00 ./fork_demo

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

僵尸进程

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

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

#include #include #include int main() {  printf("pid %d/n", getpid());  int child_pid = fork();  if (child_pid == 0) {    printf("-----in child process:  %d/n", getpid());    exit(0);  } else {    sleep(1000000);  }  return 0;}

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

UID        PID  PPID  C STIME TTY          TIME CMDya       22537 20759  0 19:57 pts/8    00:00:00 ./make_zombieya       22538 22537  0 19:57 pts/8    00:00:00 [make_zombie] 

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

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

ps -ho pid,state -p 2253822538 Z

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

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

PID 为 1 的进程

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

UID        PID  PPID  C STIME TTY          TIME CMDroot         1     0  0 12月12 ?      00:00:54 /usr/lib/systemd/systemd --system --deserialize 21

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

UID   PID  PPID   C STIME   TTY           TIME CMD  0     1     0   0 六04下午 ??        28:40.65 /sbin/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 leads to unexpected behaviour when running inside of Docker."。下图来自 github.com/nodejs/dock… 。

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

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

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

#include #include #include int main() {  printf("pid %d/n", getpid());  int child_pid = fork();  if (child_pid == 0) {    printf("-----in child process:  %d/n", getpid());    exit(0);  } else {    sleep(15);    exit(0);  }}

编译生成可执行文件 make_zombie。

gcc make_zombie.c -o make_zombie

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

const { spawn } = require('child_process');const cmd = spawn('./make_zombie');cmd.stdout.on('data', (data) => {    console.log(`stdout: ${data}`);});cmd.stderr.on('data', (data) => {    console.error(`stderr: ${data}`);});cmd.on('close', (code) => {    console.log(`child process exited with code ${code}`);});setTimeout(function () {    console.log("...");}, 1000000);

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

UID        PID  PPID  C STIME TTY          TIME CMDya       19234 19231  0 12月20 ?       00:00:00 sshd: ya@pts/6ya       19235 19234  0 12月20 pts/6   00:00:01 -zshya       29513 19235  3 15:28 pts/6    00:00:00 node run.jsya       29519 29513  0 15:28 pts/6    00:00:00 ./make_zombieya       29520 29519  0 15:28 pts/6    00:00:00 [make_zombie] 复制代码

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

UID        PID  PPID  C STIME TTY          TIME CMDya       19234 19231  0 12月20 ?       00:00:00 sshd: ya@pts/6ya       19235 19234  0 12月20 pts/6   00:00:01 -zshya       29513 19235  3 15:28 pts/6    00:00:00 node run.js

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

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

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

#指定基础镜像FROM  registry.gz.cctv.cn/library/your_node_image:your_tagWORKDIR /#复制包文件到工作目录，. 代表当前目录，也就是工作目录ADD test.tar.gz .#指定启动命令CMD ["node", "run.js"]

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

docker exec -it e37f7e3c2e39 /bin/bash 

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

UID        PID  PPID  C STIME TTY          TIME CMDroot         1     0  1 07:52 ?        00:00:00 node run.jsroot        12     1  0 07:52 ?        00:00:00 ./make_zombieroot        13    12  0 07:52 ?        00:00:00 [make_zombie] 

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

UID        PID  PPID  C STIME TTY          TIME CMDroot         1     0  0 07:52 ?        00:00:00 node run.jsroot        13     1  0 07:52 ?        00:00:00 [make_zombie] 

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

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

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

{  "name": "test-demo",  "version": "1.0.0",  "description": "",  "main": "index.js",  "scripts": {    "test": "echo /"Error: no test specified/" && exit 1",    "start": "node run.js"  },  "keywords": [],  "author": "",  "license": "ISC",  "dependencies": {  }}

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

ya       19235 19234  0 12月20 pts/6  00:00:01 -zshya       32252 19235  0 16:32 pts/6    00:00:00 npmya       32262 32252  0 16:32 pts/6    00:00:00 node run.js

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

线上问题分析

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

.|└── chrome(1)    ├── gpu-process(2)    └── zygote(3)        └── renderer(4)

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

解决办法

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

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

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

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

ADD test.tar.gz .# CMD ["npm", "run", "start"]CMD ["/bin/bash", "-c", "set -e && npm run start"]

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

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

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

#include #include static void signal_handler(int signal_no) {  if (signal_no == SIGQUIT) {    printf("quit signal receive: %d/n", signal_no);  } else if (signal_no == SIGTERM) {    printf("term signal receive: %d/n", signal_no);  } else if (signal_no == SIGTERM) {    printf("interrupt signal receive: %d/n", signal_no);  }}int main() {  printf("in main/n");  signal(SIGQUIT, signal_handler);  signal(SIGINT, signal_handler);  signal(SIGTERM, signal_handler);  getchar();}

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

kill -15 47120term signal receive: 15kill -3 47120quit signal receive: 3kill -2 47120interrupt signal receive: 2

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

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

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

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

docker run -it --init you_docker_image_id

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

以下面的 Dockerfile 内容为例

...CMD ["./signal_test"]...

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

UID        PID  PPID  C STIME TTY          TIME CMDroot         1     0  0 15:30 pts/0    00:00:00 /sbin/docker-init -- /app/node-defaultroot         6     1  0 15:30 pts/0    00:00:00 ./signal_test

可以看到 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() 调用后会产生多少新进程？

#include #include int main() {  printf("Hello, World!/n");  fork();  fork();  fork();  sleep(100);  return 0;}