一次 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 可以看到当前运行的所有进程，如下所示。

UIDPIDPPIDCSTIMETTYTIMECMD
0100六04下午??23:09.18/sbin/launchd
03910六04下午??0:49.66/usr/sbin/syslogd
04010六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 命令过程的进程关系如下所示。

UIDPIDPPIDCSTIMETTYTIMECMD
50132110六04下午??61:01.45/Applications/iTerm.app/Contents/MacOS/iTerm2-psn_0_81940
5019792032108:02上午ttys0390:00.07/Applications/iTerm.app/Contents/MacOS/iTerm2--serverlogin-fparthur
0979219792008:02上午ttys0390:00.03login-fparthur
501979229792108:02上午ttys0390:00.29-zsh
501983699792208:14上午ttys0390:00.00./a.out

进程与 fork

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

#include<unistd.h>
#include<stdio.h>

intmain(){
intret=fork();
if(ret){
printf("enterifblock\n");
}else{
printf("enterelseblock\n");
}
return0;
}

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

enterifblock
enterelseblock

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

fork 调用

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

pid_tfork(void);

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

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

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

#include<unistd.h>
#include<stdio.h>
#include<stdlib.h>

intmain(){
printf("beforefork,pid=%d\n",getpid());
pid_tchildPid;
switch(childPid=fork()){
case-1:{
//fork失败
printf("forkerror,%d\n",getpid());
exit(1);
}
case0:{
//子进程代码进入到这里
printf("inchildprocess,pid=%d\n",getpid());
break;
}
default:{
//父进程代码进入到这里
printf("inparentprocess,pid=%d,childpid=%d\n",getpid(),childPid);
break;
}
}
return0;
}

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

beforefork,pid=26070
inparentprocess,pid=26070,childpid=26071
inchildprocess,pid=26071

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

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

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

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

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

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

#include<unistd.h>
#include<stdio.h>
#include<stdlib.h>

intmain(){
printf("beforefork,pid=%d\n",getpid());
pid_tchildPid;
switch(childPid=fork()){
case-1:{
printf("forkerror,%d\n",getpid());
exit(1);
}
case0:{
printf("inchildprocess,pid=%d\n",getpid());
sleep(100000);//子进程sleep不退出
break;
}
default:{
printf("inparentprocess,pid=%d,childpid=%d\n",getpid(),childPid);
exit(0);//父进程退出
}
}
return0;
}

编译运行上面的代码

gccfork_demo.c-ofork_demo;./fork_demo

输出结果如下。

beforefork,pid=21629
inparentprocess,pid=21629,childpid=21630
inchildprocess,pid=21630

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

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

UIDPIDPPIDCSTIMETTYTIMECMD
root10012月12?00:00:53/usr/lib/systemd/systemd--system--deserialize21
ya216301019:26pts/800:00:00./fork_demo

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

僵尸进程

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

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

#include<stdio.h>
#include<stdlib.h>
#include<unistd.h>

intmain(){

printf("pid%d\n",getpid());
intchild_pid=fork();
if(child_pid==0){
printf("-----inchildprocess:%d\n",getpid());
exit(0);
}else{
sleep(1000000);
}
return0;
}

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

UIDPIDPPIDCSTIMETTYTIMECMD
ya2253720759019:57pts/800:00:00./make_zombie
ya2253822537019:57pts/800:00:00[make_zombie]<defunct>

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

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

ps-hopid,state-p22538
22538Z

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

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

PID 为 1 的进程

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

UIDPIDPPIDCSTIMETTYTIMECMD
root10012月12?00:00:54/usr/lib/systemd/systemd--system--deserialize21

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

UIDPIDPPIDCSTIMETTYTIMECMD
0100六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<stdio.h>
#include<stdlib.h>
#include<unistd.h>

intmain(){
printf("pid%d\n",getpid());
intchild_pid=fork();
if(child_pid==0){
printf("-----inchildprocess:%d\n",getpid());
exit(0);
}else{
sleep(15);
exit(0);
}
}

编译生成可执行文件 make_zombie。

gccmake_zombie.c-omake_zombie

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

const{spawn}=require('child_process');
constcmd=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(`childprocessexitedwithcode${code}`);
});
setTimeout(function(){
console.log("...");
},1000000);

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

UIDPIDPPIDCSTIMETTYTIMECMD
ya1923419231012月20?00:00:00sshd:ya@pts/6
ya1923519234012月20pts/600:00:01-zsh
ya2951319235315:28pts/600:00:00noderun.js
ya2951929513015:28pts/600:00:00./make_zombie
ya2952029519015:28pts/600:00:00[make_zombie]<defunct>

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

UIDPIDPPIDCSTIMETTYTIMECMD
ya1923419231012月20?00:00:00sshd:ya@pts/6
ya1923519234012月20pts/600:00:01-zsh
ya2951319235315:28pts/600:00:00noderun.js

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

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

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

#指定基础镜像
FROMregistry.gz.cctv.cn/library/your_node_image:your_tag

WORKDIR/

#复制包文件到工作目录，.代表当前目录，也就是工作目录
ADDtest.tar.gz.

#指定启动命令
CMD["node","run.js"]

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

dockerexec-ite37f7e3c2e39/bin/bash

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

UIDPIDPPIDCSTIMETTYTIMECMD
root10107:52?00:00:00noderun.js
root121007:52?00:00:00./make_zombie
root1312007:52?00:00:00[make_zombie]<defunct>

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

UIDPIDPPIDCSTIMETTYTIMECMD
root10007:52?00:00:00noderun.js
root131007:52?00:00:00[make_zombie]<defunct>

可以看到 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:notestspecified\"&&exit1",
"start":"noderun.js"
},
"keywords":[],
"author":"",
"license":"ISC",
"dependencies":{
}
}

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

ya1923519234012月20pts/600:00:01-zsh
ya3225219235016:32pts/600:00:00npm
ya3226232252016:32pts/600:00:00noderun.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，如下所示。

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

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

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

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

#include<signal.h>
#include<stdio.h>

staticvoidsignal_handler(intsignal_no){
if(signal_no==SIGQUIT){
printf("quitsignalreceive:%d\n",signal_no);
}elseif(signal_no==SIGTERM){
printf("termsignalreceive:%d\n",signal_no);
}elseif(signal_no==SIGTERM){
printf("interruptsignalreceive:%d\n",signal_no);
}
}

intmain(){
printf("inmain\n");

signal(SIGQUIT,signal_handler);
signal(SIGINT,signal_handler);
signal(SIGTERM,signal_handler);

getchar();
}

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

kill-1547120
termsignalreceive:15

kill-347120
quitsignalreceive:3

kill-247120
interruptsignalreceive:2

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

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

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

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

dockerrun-it--inityou_docker_image_id

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

以下面的 Dockerfile 内容为例

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

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

UIDPIDPPIDCSTIMETTYTIMECMD
root10015:30pts/000:00:00/sbin/docker-init--/app/node-default
root61015:30pts/000: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<stdio.h>
#include<unistd.h>

intmain(){
printf("Hello,World!\n");

fork();
fork();
fork();
sleep(100);
return0;
}