• GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。

一、发现问题

小玲是一名数据库测试人员，这一天她尝试在docker环境中部署GreatDB集群，后果在对greatsqld过程进行kill操作后，意外发现greatsqld过程变成了僵尸过程（如下图所示）。

因为小玲成为测试人员的工夫较短，她没有遇见过这种状况，所以无奈第一工夫判断这个景象，是她的操作失误导致的正当景象，还是一个新发现的bug。

于是她进行了以下尝试：

• 1.在物理机上反复上述操作，并没有呈现僵尸过程。
• 2.在docker内，对MySQL的mysqld过程进行雷同操作，呈现了僵尸过程。

通过这样的尝试，小玲初步判断出docker环境才是产生僵尸过程的本源，但具体是什么起因，又该如何防止，还须要小玲的进一步摸索。

二、僵尸过程简介

首先须要搞清楚的是：

• 僵尸过程是什么？
• 僵尸过程又是如何造成的？

以下定义内容和解决办法来自维基百科。

僵尸过程：在类UNIX零碎中，僵尸过程是指实现执行（通过exit零碎调用，或运行时产生致命谬误或收到终止信号所致），但在操作系统的过程表中依然存在其过程管制块(PCB)，处于"终止状态"的过程。僵尸过程不能被杀死，因为它们曾经死亡，只期待它们的父过程回收它们。

通过这样的概念，和其余一些相干资料，小玲理解了僵尸过程的呈现，问题多半是呈现僵尸过程的父过程上。

这时，小玲看到了一个比较简单粗犷的解决办法，就是间接将僵尸过程的父过程杀死。她立即去实际了一番，惋惜她又失败了。

在docker中，她kill产生的僵尸过程的父过程PID是1，而1这个过程在docker外部是kill不掉的；如果在docker内部的物理机找到1的对应过程进行kill，则会将整个容器杀死。

三、孤儿过程的呈现

小玲并不泄气，她持续通过搜索引擎进行摸索学习，很快她就理解到更多的概念。

当过程的父过程id变为1的时候，这个过程也有了专门定义的称呼，叫做孤儿过程。

孤儿过程：父过程完结后仍在运行的子过程。

没有了父过程总要有人“关照”它。

在类UNIX操作系统中，为防止孤儿过程退出时无奈开释所占用的资源而僵死，任何孤儿过程产生时都会立刻被零碎过程init或systemd主动接管为子过程，这一过程也被称为“收养”。在此需注意，尽管事实上该过程已有init作为其父过程，但因为创立该过程的过程已不存在，所以仍应称之为“孤儿过程”。

依据下面的解释，又引出来一个概念，init 过程。咱们也来看下它的定义。

init过程:是 Unix 和 类Unix 零碎中用来产生其它所有过程的程序。它以守护过程的形式存在，其过程号为1。init过程是非凡的：它不取得它不想解决的信号，因而它能够疏忽SIGKILL。

这里又有个新概念，SIGKILL信号。

个别咱们kill过程是发信号给过程，而后被过程捕捉之后执行对应操作。次要须要理解的信号有上面3种。都是来终止过程应用的。

四、整顿景象产生的过程

小玲曾经分明这个景象跟GreatDB和MySQL都没有关系了，于是应用sleep命令持续尝试。

进入容器，执行命令。此时子过程PID是61，父过程PID是44，父过程是bash。

退出容器，再进入容器。PID是44的bash过程因为退出容器的操作被杀死，子过程61就被init收养了，父过程的PID就变成了1。

杀掉这个过程61，而后查看这个过程状态，发现它曾经成为一个僵尸过程。

到这里，小玲就曾经很靠近问题的假相了：docker容器在默认的参数配置下，其init过程并没有解决孤儿过程的能力。

对于这个问题，docker的开发者们曾经思考到了。

五、如何解决docker中的僵尸过程

有两个解决办法能够让docker的init过程可能解决孤儿过程。

1.启动docker容器时，指定init过程为bash，由bash过程对孤儿过程的资源进行回收。

2.减少专门的 init 过程，比方 tini。

咱们能够去docker官网文档找到答案：

The container’s main process is responsible for managing all processes that it starts.In some cases， the main process isn’t well-designed， and doesn’t handle “reaping” (stopping) child processes gracefully when the container exits.If your process falls into this category， you can use the --init option when you run the container.The --init flag inserts a tiny init-process into the container as the main process， and handles reaping of all processes when the container exits.Handling such processes this way is superior to using a full-fledged init process such as sysvinit， upstart， or systemd to handle process lifecycle within your container.

依据文档倡议，能够在启动容器时候加上 --init 参数，开始应用tini。这样会有一个tiny的过程来负责过程"收养"之后的解决工作。

接下来咱们别离对两种办法进行验证。

5.1 bash 解决

咱们尝试将启动容器的命令指定为bash来启动一个容器test01，来看下这个容器会不会呈现文章结尾的问题。

启动容器，指定命令为bash。这个镜像基于CentOS 7的镜像，装了一些罕用的包。

进入test01，确认id为1的过程。

执行sleep 700s &，而后查看父过程id为16，子过程id为33。

退出，从新登录容器test01，查看过程33的父过程，曾经被init过程“领养”。

kill 过程33。而后check过程33。发现33没有成为僵尸，曾经彻底被终止了。

从下面步骤来看，指定启动命令为bash的确能够解决咱们遇到的问题。

5.2 tini 解决

再来试下tini，它是应用C语言写的一个tiny级的init过程，github对此有具体的介绍。

这是一个相当轻量级的init零碎，相比拟传统的Upstart、Systemd、SysV init 之类的大型零碎应用起来更加的优良。

当初咱们在启动docker容器时时候加上--init参数，来看下成果。

加上init参数，启动容器test02，启动命令应用tail -f /dev/null，而后登录查看过程状况。

登录test02，执行sleep 700s &。查看父子过程id。

退出登录。

再次登录之后，查看过程的父过程id。

kill过程，查看过程是否彻底终止。曾经看到没有僵尸过程。

六、总结

在应用tail -f /dev/null作为docker容器的init过程时，如果不加上--init参数，就会因为init过程没有解决孤儿过程的能力，而导致僵尸过程的呈现。

在这种状况下，咱们能够将tail -f /dev/null替换成bash，或是加上--init来解决这个问题。

文章举荐：

GreatSQL MGR FAQ
https://mp.weixin.qq.com/s/J6...

万答#12，MGR整个集群挂掉后，如何能力主动选主，不必手动干涉
https://mp.weixin.qq.com/s/07...

『2021数据技术嘉年华·ON LINE』：《MySQL高可用架构演进及实际》
https://mp.weixin.qq.com/s/u7...

一条sql语句慢在哪之抓包剖析
https://mp.weixin.qq.com/s/AY...

万答#15，都有哪些状况可能导致MGR服务无奈启动
https://mp.weixin.qq.com/s/in...

技术分享 | 为什么MGR一致性模式不举荐AFTER
https://mp.weixin.qq.com/s/rN...

对于 GreatSQL

GreatSQL是由万里数据库保护的MySQL分支，专一于晋升MGR可靠性及性能，反对InnoDB并行查问个性，是实用于金融级利用的MySQL分支版本。

Gitee:
https://gitee.com/GreatSQL/Gr...

GitHub:
https://github.com/GreatSQL/G...

Bilibili：
https://space.bilibili.com/13...

微信&QQ群：
可搜寻增加GreatSQL社区助手微信好友，发送验证信息“加群”退出GreatSQL/MGR交换微信群

QQ群：533341697
微信小助手：wanlidbc

本文由博客一文多发平台 OpenWrite 公布！