一次 Docker 容器內(nèi)大量僵尸進(jìn)程排查分析
前段時(shí)間線上的一個(gè)使用 Google Puppeteer 生成圖片的服務(wù)炸了,每個(gè) docker 容器內(nèi)都有幾千個(gè)孤兒僵死進(jìn)程沒(méi)有回收,如下圖所示。
這篇文章比較長(zhǎng),主要就講了下面這幾個(gè)問(wèn)題。
- 什么情況下會(huì)出現(xiàn)僵尸進(jìn)程、孤兒進(jìn)程
- Puppeteer 工作過(guò)程啟動(dòng)的進(jìn)程與線上事故分析
- PID 為 1 的進(jìn)程有什么特殊的地方
- 為什么 node/npm 不應(yīng)該作為鏡像中 PID 為 1 的進(jìn)程
- 為什么 Bash 可以作為 PID 為 1 的進(jìn)程,以及它做 PID 為 1 的進(jìn)程有什么缺陷
- 鏡像中比較推薦的 init 進(jìn)程的做法是什么
Puppeteer 是一個(gè) node 庫(kù),是 Chrome 官方提供的無(wú)界面 chrome 工具(headless chrome),它提供了操作 Chrome API 的方式,允許開(kāi)發(fā)者在程序中啟動(dòng) chrome 進(jìn)程,調(diào)用 JS 的 API 實(shí)現(xiàn)頁(yè)面加載、數(shù)據(jù)爬取、web 自動(dòng)化測(cè)試等功能。
本案例中使用的場(chǎng)景是使用 Puppeteer 加載 html,隨后截圖生成一張分銷(xiāo)海報(bào)的圖片。文章分析了這個(gè)問(wèn)題背后的原因,接下來(lái)開(kāi)始正式的內(nèi)容。
進(jìn)程
每個(gè)進(jìn)程都有一個(gè)唯一的標(biāo)識(shí),稱為 pid,pid 是一個(gè)非負(fù)的整數(shù)值,使用 ps 命令可以查看,在我的 Mac 電腦上執(zhí)行 ps -ef 可以看到當(dāng)前運(yùn)行的所有進(jìn)程,如下所示。
- 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 是表示進(jìn)程號(hào)。
系統(tǒng)中每個(gè)進(jìn)程都有對(duì)應(yīng)的父進(jìn)程,上面 ps 輸出中的 PPID 就表示進(jìn)程的父進(jìn)程號(hào)。最頂層的進(jìn)程的 PID 為 1,PPID 為 0。
打開(kāi) iTerm,在終端中執(zhí)行一個(gè)命令,比如 "ls",實(shí)際上系統(tǒng)會(huì)創(chuàng)建新的 iTerm 子進(jìn)程,這個(gè) iTerm 進(jìn)程又創(chuàng)建了 zsh 子進(jìn)程。在 zsh 中輸入的 ls 命令,則是 zsh 進(jìn)程又啟動(dòng)了一個(gè) ls 子進(jìn)程。在 iTerm 中輸入 ls 命令過(guò)程的進(jìn)程關(guān)系如下所示。
- 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
進(jìn)程與 fork
前面提到的父進(jìn)程“創(chuàng)建”子進(jìn)程,更嚴(yán)謹(jǐn)?shù)拿枋鍪?fork(孵化、衍生)。下面來(lái)看一個(gè)實(shí)際的例子,新建一個(gè) fork_demo.c 文件。
- #include <unistd.h>
- #include <stdio.h>
- int main() {
- int ret = fork();
- if (ret) {
- printf("enter if block\n");
- } else {
- printf("enter else block\n");
- }
- return 0;
- }
執(zhí)行上的代碼,會(huì)輸出如下的語(yǔ)句。
- enter if block
- enter else block
可以看到 if、else 語(yǔ)句都被執(zhí)行了。
fork 調(diào)用
fork 是一個(gè)系統(tǒng)調(diào)用,它的方法聲明如下所示。
- pid_t fork(void);
fork 調(diào)用完成后會(huì)生成一個(gè)新的子進(jìn)程,且父子進(jìn)程都從 fork 返回處繼續(xù)執(zhí)行。這里需要特別注意的是 fork 的返回值的含義,在父進(jìn)程和新的子進(jìn)程中,它們的含義不一樣。
- 在父進(jìn)程中 fork 的返回值是新創(chuàng)建的子進(jìn)程 id
- 在創(chuàng)建的子進(jìn)程中 fork 的返回值始終等于 0
因此可以通過(guò) fork 的返回值區(qū)分父子進(jìn)程,在運(yùn)行過(guò)程中可以使用 getpid 方法獲取當(dāng)前的進(jìn)程 id。fork 典型的使用方式如下所示。
- #include <unistd.h>
- #include <stdio.h>
- #include <stdlib.h>
- 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: {
- // 子進(jìn)程代碼進(jìn)入到這里
- printf("in child process, pid=%d\n", getpid());
- break;
- }
- default: {
- // 父進(jìn)程代碼進(jìn)入到這里
- printf("in parent process, pid=%d, child pid=%d\n", getpid(), childPid);
- break;
- }
- }
- return 0;
- }
執(zhí)行上面的代碼,輸出結(jié)果如下所示。
- before fork, pid=26070
- in parent process, pid=26070, child pid=26071
- in child process, pid=26071
子進(jìn)程是父進(jìn)程的副本,子進(jìn)程擁有父進(jìn)程數(shù)據(jù)空間、堆、棧的復(fù)制副本 ,fork 采用了 copy-on-write 技術(shù),fork 操作幾乎瞬間可以完成。只有在子進(jìn)程修改了相應(yīng)的區(qū)域才會(huì)進(jìn)行真正的拷貝。
孤兒進(jìn)程:不能同年同月同日生,也不會(huì)同年同月同日死
接下來(lái)問(wèn)一個(gè)問(wèn)題,父進(jìn)程掛掉時(shí),子進(jìn)程會(huì)掛掉嗎?
想象現(xiàn)實(shí)中的場(chǎng)景,父親不在了,兒子還可以活嗎?答案是肯定的。對(duì)應(yīng)于進(jìn)程,父進(jìn)程退出時(shí),子進(jìn)程會(huì)繼續(xù)運(yùn)行,不會(huì)一起共赴黃泉。
一個(gè)父進(jìn)程已經(jīng)終止的進(jìn)程被稱為孤兒進(jìn)程(orphan process)。操作系統(tǒng)這個(gè)大家長(zhǎng)是比較人性化的,沒(méi)有人管的孤兒進(jìn)程會(huì)被進(jìn)程 ID 為 1 的進(jìn)程接管。這個(gè) PID 為 1 的進(jìn)程后面還會(huì)再講到。
接下來(lái)對(duì)之前的代碼稍作修改,讓父進(jìn)程 fork 子進(jìn)程以后自殺退出,生成孤兒進(jìn)程。代碼如下所示。
- #include <unistd.h>
- #include <stdio.h>
- #include <stdlib.h>
- 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); // 子進(jìn)程 sleep 不退出
- break;
- }
- default: {
- printf("in parent process, pid=%d, child pid=%d\n", getpid(), childPid);
- exit(0); // 父進(jìn)程退出
- }
- }
- return 0;
- }
編譯運(yùn)行上面的代碼
- gcc fork_demo.c -o fork_demo; ./fork_demo
輸出結(jié)果如下。
- before fork, pid=21629
- in parent process, pid=21629, child pid=21630
- in child process, pid=21630
可以看到父進(jìn)程 id 為 21629, 生成的子進(jìn)程 id 為 21630。
使用 ps 查看當(dāng)前進(jìn)程信息,結(jié)果如下所示。
- UID PID PPID C STIME TTY TIME CMD
- root 1 0 0 12月12 ? 00:00:53 /usr/lib/systemd/systemd --system --deserialize 21
- ya 21630 1 0 19:26 pts/8 00:00:00 ./fork_demo
可以看到此時(shí)孤兒子進(jìn)程 21630 的父 ID 已經(jīng)變?yōu)榱隧攲拥?ID 為 1 的進(jìn)程。
僵尸進(jìn)程
父進(jìn)程負(fù)責(zé)生,如果不負(fù)責(zé)養(yǎng),那就不是一個(gè)好父親。子進(jìn)程掛了,如果父進(jìn)程不給子進(jìn)程“收尸”(調(diào)用 wait/waitpid),那這個(gè)子進(jìn)程小可憐就變成了僵尸進(jìn)程。
新建一個(gè) make_zombie.c 文件,內(nèi)容如下。
- #include <stdio.h>
- #include <stdlib.h>
- #include <unistd.h>
- 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;
- }
編譯運(yùn)行上面的代碼,就可以生成一個(gè)進(jìn)程號(hào)為 22538 的僵尸進(jìn)程,如下所示。
- UID PID PPID C STIME TTY TIME CMD
- ya 22537 20759 0 19:57 pts/8 00:00:00 ./make_zombie
- ya 22538 22537 0 19:57 pts/8 00:00:00 [make_zombie] <defunct>
CMD 名中的 defunct 表示這是一個(gè)僵尸進(jìn)程。
也使用 ps 命令查看進(jìn)程的狀態(tài),顯示為 "Z" 或者 "Z+" 表示這是一個(gè)僵尸進(jìn)程,如下所示。
- ps -ho pid,state -p 22538
- 22538 Z
子進(jìn)程退出后絕大部分資源已經(jīng)被釋放可供其他進(jìn)使用,但是內(nèi)核的進(jìn)程表中的槽位沒(méi)有釋放。
僵尸進(jìn)程有一個(gè)很神奇的特性,使用 kill -9 必殺信號(hào)都沒(méi)有辦法殺掉僵尸進(jìn)程,這樣的設(shè)計(jì)利弊參半,好的地方是父進(jìn)程可以總是有機(jī)會(huì)執(zhí)行 wait/waitpid 等命令收割子進(jìn)程,壞的地方是無(wú)法強(qiáng)制回收這種僵尸進(jìn)程。
PID 為 1 的進(jìn)程
Linux 中內(nèi)核初始化以后會(huì)啟動(dòng)系統(tǒng)的第一個(gè)進(jìn)程,PID 為 1,也可以稱之為 init 進(jìn)程或者根(ROOT)進(jìn)程。在我的 Centos 機(jī)器上,這個(gè) init 進(jìn)程是 systemd,如下所示。
- UID PID PPID C STIME TTY TIME CMD
- root 1 0 0 12月12 ? 00:00:54 /usr/lib/systemd/systemd --system --deserialize 21
在我的 Mac 電腦上,這個(gè)進(jìn)程為 launchd,如下所示。
- UID PID PPID C STIME TTY TIME CMD
- 0 1 0 0 六04下午 ?? 28:40.65 /sbin/launchd
init 進(jìn)程有下面這幾個(gè)功能
- 如果一個(gè)進(jìn)程的父進(jìn)程退出了,那么這個(gè) init 進(jìn)程便會(huì)接管這個(gè)孤兒進(jìn)程。
- 如果一個(gè)進(jìn)程的父進(jìn)程未執(zhí)行 wait/waitpid 就退出了,init 進(jìn)程會(huì)接管子進(jìn)程并自動(dòng)調(diào)用 wait 方法,從而保證系統(tǒng)中的僵尸進(jìn)程可以被移除。
- 傳遞信號(hào)給子進(jìn)程,這點(diǎn)后面會(huì)介紹。
為什么 Node.js 不適合做 Docker 鏡像中 PID 為 1 的進(jìn)程
在 Node.js 的官方最佳實(shí)踐里有寫(xiě)到 "Node.js was not designed to run as PID 1 which leads to unexpected behaviour when running inside of Docker."。下圖來(lái)自 github.com/nodejs/dock… 。
接下來(lái)會(huì)做兩個(gè)實(shí)驗(yàn):第一個(gè)實(shí)驗(yàn)是在 Centos 機(jī)器上,第二個(gè)實(shí)驗(yàn)是在 Docker 鏡像中
實(shí)驗(yàn)一:在 Centos 上,systemd 作為 PID 為 1 的進(jìn)程
下面來(lái)做一些測(cè)試,修改上面的代碼,將父進(jìn)程 sleep 的時(shí)間改短為 15s,新建一個(gè) make_zombie.c 文件,如下所示。
- #include <stdio.h>
- #include <stdlib.h>
- #include <unistd.h>
- 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);
- }
- }
編譯生成可執(zhí)行文件 make_zombie。
- gcc make_zombie.c -o make_zombie
然后新建一個(gè) run.js 代碼,內(nèi)部啟動(dòng)一個(gè)進(jìn)程運(yùn)行 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);
執(zhí)行 node run.js 運(yùn)行這段 js 代碼,使用 ps -ef 查看進(jìn)程關(guān)系如下。
- UID PID PPID C STIME TTY TIME CMD
- ya 19234 19231 0 12月20 ? 00:00:00 sshd: ya@pts/6
- ya 19235 19234 0 12月20 pts/6 00:00:01 -zsh
- ya 29513 19235 3 15:28 pts/6 00:00:00 node run.js
- ya 29519 29513 0 15:28 pts/6 00:00:00 ./make_zombie
- ya 29520 29519 0 15:28 pts/6 00:00:00 [make_zombie] <defunct>
過(guò) 15s 以后,再次執(zhí)行 ps -ef 查詢當(dāng)前運(yùn)行的進(jìn)程,可以看到 make_zombie 相關(guān)進(jìn)程都不見(jiàn)了。
- UID PID PPID C STIME TTY TIME CMD
- ya 19234 19231 0 12月20 ? 00:00:00 sshd: ya@pts/6
- ya 19235 19234 0 12月20 pts/6 00:00:01 -zsh
- ya 29513 19235 3 15:28 pts/6 00:00:00 node run.js
這是因?yàn)?PID 為 29519 的 make_zombie 父進(jìn)程在 15s 以后退出,僵尸子進(jìn)程被托管到 init 進(jìn)程,這個(gè)進(jìn)程會(huì)調(diào)用 wait/waitfor 為這個(gè)僵尸收尸。
實(shí)驗(yàn)二:在 Docker 上,node 作為 PID 為 1 的進(jìn)程
將 make_zombie 可執(zhí)行文件和 run.js 打包為 .tar.gz 包,隨后新建一個(gè) Dockerfile,內(nèi)容如下。
- #指定基礎(chǔ)鏡像
- FROM registry.gz.cctv.cn/library/your_node_image:your_tag
- WORKDIR /
- #復(fù)制包文件到工作目錄,. 代表當(dāng)前目錄,也就是工作目錄
- ADD test.tar.gz .
- #指定啟動(dòng)命令
- CMD ["node", "run.js"]
執(zhí)行 docker build 命令構(gòu)建一個(gè)鏡像,在我的電腦上 Image ID 為 ab71925b5154, 執(zhí)行 docker run ab71925b5154,啟動(dòng) docker 鏡像,使用 docker ps 找到鏡像 CONTAINER ID,這里為 e37f7e3c2e39。隨即使用 docker exec 進(jìn)入到鏡像終端
- docker exec -it e37f7e3c2e39 /bin/bash
執(zhí)行 ps 命令查看當(dāng)前的進(jìn)程狀況,如下所示。
- UID PID PPID C STIME TTY TIME CMD
- root 1 0 1 07:52 ? 00:00:00 node run.js
- root 12 1 0 07:52 ? 00:00:00 ./make_zombie
- root 13 12 0 07:52 ? 00:00:00 [make_zombie] <defunct>
等一段時(shí)間(15s),再次執(zhí)行 ps 查看當(dāng)前進(jìn)程,如下所示。
- UID PID PPID C STIME TTY TIME CMD
- root 1 0 0 07:52 ? 00:00:00 node run.js
- root 13 1 0 07:52 ? 00:00:00 [make_zombie] <defunct>
可以看到 PID 為 13 的僵尸進(jìn)程已經(jīng)托管到 PID 為 1 的 node 進(jìn)程,但是沒(méi)有被回收。
這是 node 不適合做 init 進(jìn)程的最主要原因:無(wú)法回收僵尸進(jìn)程。
說(shuō)到 node,這里提一下 npm,npm 實(shí)際上是使用 npm 進(jìn)程啟動(dòng)了一個(gè)子進(jìn)程啟動(dòng)了 package.json 中 scripts 里寫(xiě)的啟動(dòng)腳本,示例 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 啟動(dòng),得到的進(jìn)程如下所示。
- ya 19235 19234 0 12月20 pts/6 00:00:01 -zsh
- ya 32252 19235 0 16:32 pts/6 00:00:00 npm
- ya 32262 32252 0 16:32 pts/6 00:00:00 node run.js
與 node 一樣,npm 也不會(huì)處理僵尸子進(jìn)程回收。
線上問(wèn)題分析
我們線上出問(wèn)題的情況下使用 npm start 來(lái)啟動(dòng)一個(gè) Puppeteer 項(xiàng)目,每生成一次圖片便會(huì)創(chuàng)建 4 個(gè) chrome 相關(guān)的進(jìn)程,如下所示。
- .
- |
- └── chrome(1)
- ├── gpu-process(2)
- └── zygote(3)
- └── renderer(4)
在圖片生成完成時(shí),chrome 主進(jìn)程退出,剩下的三個(gè)孤兒僵尸進(jìn)程被托管到頂層 npm 進(jìn)程下,但是 npm 進(jìn)程無(wú)力回收,所有每生成一次圖片便會(huì)新增三個(gè)僵尸進(jìn)程。在成千上萬(wàn)次圖片生成以后,系統(tǒng)中就充滿了僵尸進(jìn)程。
解決辦法
為了解決這個(gè)問(wèn)題,不能讓 node/npm 成為 init 進(jìn)程,讓有能力接管僵尸進(jìn)程的服務(wù)成為 init 進(jìn)程即可,有兩個(gè)解決辦法。
- 使用 bash 啟動(dòng) node 或者 npm
- 增加專門(mén)的 init 進(jìn)程,比如 tini
解決方式一:使用 bash 啟動(dòng) node
讓 bash 成為頂層進(jìn)程是比較快的一種方式,bash 進(jìn)程會(huì)負(fù)責(zé)回收僵尸進(jìn)程,修改 Dockerfile,如下所示。
- ADD test.tar.gz .
- # CMD ["npm", "run", "start"]
- CMD ["/bin/bash", "-c", "set -e && npm run start"]
使用這種方式是比較簡(jiǎn)單,而且之前線上沒(méi)有出問(wèn)題正是因?yàn)橐婚_(kāi)始是使用這種 bash 方式啟動(dòng) node,后面有一個(gè)小兄弟為了統(tǒng)一啟動(dòng)命令將這個(gè)命令改為 npm run start,問(wèn)題才出現(xiàn)的。
但使用 bash 并非完美的方案,它有一個(gè)比較嚴(yán)重的問(wèn)題,bash 不會(huì)傳遞信號(hào)給它啟動(dòng)的進(jìn)程,優(yōu)雅停機(jī)等功能無(wú)法實(shí)現(xiàn)。
接下來(lái)做一個(gè)實(shí)驗(yàn),驗(yàn)證 bash 不會(huì)傳遞信號(hào)給子進(jìn)程的說(shuō)法,新建一個(gè) signal_test.c 文件,它處理 SIGQUIT、SIGTERM、SIGTERM 三個(gè)信號(hào),內(nèi)容如下。
- #include <signal.h>
- #include <stdio.h>
- 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 上運(yùn)行這個(gè) signal_test 程序時(shí),發(fā)送 kill -2、-3、-15 給這個(gè)程序,都會(huì)有對(duì)應(yīng)的打印輸出,表示收到了信號(hào)。如下所示。
- kill -15 47120
- term signal receive: 15
- kill -3 47120
- quit signal receive: 3
- kill -2 47120
- interrupt signal receive: 2
在 Docker 鏡像中使用 bash 啟動(dòng)這個(gè)程序時(shí),發(fā)送 kill 命令給 bash 以后,bash 并不會(huì)將信號(hào)傳遞給 signal_test 程序。在執(zhí)行 docker stop 以后,docker 會(huì)發(fā)送 SIGTERM(15) 信號(hào)給 bash,bash 并不會(huì)將這個(gè)信號(hào)傳遞給啟動(dòng)的應(yīng)用程序,只能等一段時(shí)間超時(shí),docker 會(huì)發(fā)送 kill -9 強(qiáng)制殺死這個(gè) docker 進(jìn)程,無(wú)法達(dá)到優(yōu)雅停機(jī)的功能。
于是有了下面的第二種解決方案。
解決方式二:使用專門(mén)的 init 進(jìn)程
Node.js 提供了兩種方案,第一種是使用 docker 官方的輕量級(jí) init 系統(tǒng),如下所示。
- docker run -it --init you_docker_image_id
這種啟動(dòng)方式會(huì)以 /sbin/docker-init 為 PID 為 1 的 init 進(jìn)程,不會(huì)把 Dockerfile 中 CMD 作為第一個(gè)啟動(dòng)進(jìn)程。
以下面的 Dockerfile 內(nèi)容為例
- ...
- CMD ["./signal_test"]
- ...
執(zhí)行 docker run -it --init image_id 啟動(dòng) docker 鏡像,此時(shí)鏡像內(nèi)的進(jìn)程如下所示。
- UID PID PPID C STIME TTY TIME CMD
- root 1 0 0 15:30 pts/0 00:00:00 /sbin/docker-init -- /app/node-default
- root 6 1 0 15:30 pts/0 00:00:00 ./signal_test
可以看到 signal_test 程序作為 docker-init 的子進(jìn)程啟動(dòng)了。
在 docker stop 命令發(fā)送 SIGTERM 信號(hào)給鏡像以后,docker-init 進(jìn)程會(huì)將這個(gè)信號(hào)轉(zhuǎn)給 signal_test,這個(gè)應(yīng)用進(jìn)程就可以收到 SIGTERM 信號(hào)做自定義的處理,比如優(yōu)雅停機(jī)等。
除了 docker 的官方方案,Node.js 的最佳實(shí)踐還推薦了一個(gè) tini 這樣一個(gè) C 語(yǔ)言寫(xiě)的極小的 init 進(jìn)程,github.com/krallin/tin… 。它的代碼較短,很值得一讀,對(duì)理解信號(hào)傳遞、處理僵尸進(jìn)程非常有幫助。
小結(jié)
通過(guò)這篇文章,希望你可以搞懂僵尸進(jìn)程、孤兒進(jìn)程、PID 為 1 的進(jìn)程是什么,以及為什么 node/npm 不適合做 PID 為 1 的進(jìn)程,bash 作為 PID 為 1 的進(jìn)程有什么缺陷。
下面留一個(gè)作業(yè)題,考考你對(duì)進(jìn)程 fork 函數(shù)的理解。如下程序連續(xù)調(diào)用三次 fork() 調(diào)用后會(huì)產(chǎn)生多少新進(jìn)程?
- #include <stdio.h>
- #include <unistd.h>
- int main() {
- printf("Hello, World!\n");
- fork();
- fork();
- fork();
- sleep(100);
- return 0;
- }