一個 Node 進程的死亡與善后

作者：山月行 2021-03-13 12:54:50

開發前端

人固有一死，一個 Node 進程亦是如此，總有萬般不愿也無法避免。從本篇文章我們看看一個進程滅亡時如何從容離去。

[[387380]]

本文轉載自微信公眾號「全棧成長之路」，作者山月行。轉載本文請聯系全棧成長之路公眾號。

嗯，這是山月好久沒有更新的原創，正文從下開始。

人固有一死，一個 Node 進程亦是如此，總有萬般不愿也無法避免。從本篇文章我們看看一個進程滅亡時如何從容離去。

一個 Node 進程，除了提供 HTTP 服務外，也絕少不了跑腳本的身影。跑一個腳本拉取配置、處理數據以及定時任務更是家常便飯。在一些重要流程中能夠看到腳本的身影：

CI，用以測試、質量保障及部署等
Cron，用以定時任務
Docker，用以構建鏡像

如果在這些重要流程中腳本出錯無法及時發現問題，將有可能引發更加隱蔽的問題。如果在 HTTP 服務出現問題時，無法捕獲，服務異常是不可忍受的。

最近觀察項目鏡像構建，會偶爾發現一兩個鏡像雖然構建成功，但容器卻跑不起來的情況究其原因，是因為一個 Node 進程滅亡卻未曾感知到的問題。

Exit Code

什么是 exit code?

exit code 代表一個進程的返回碼，通過系統調用 exit_group 來觸發。

在 POSIX 中，0 代表正常的返回碼，1-255 代表異常返回碼，在業務實踐中，一般主動拋出的錯誤碼都是 1。在 Node 應用中調用 API process.exitCode = 1 來代表進程因期望外的異常而中斷退出。

這里有一張關于異常碼的附表 Appendix E. Exit Codes With Special Meanings[1]。

Exit Code Number	Meaning	Example	Comments
1	Catchall for general errors	let "var1 = 1/0"	Miscellaneous errors, such as "divide by zero" and other impermissible operations
2	Misuse of shell builtins (according to Bash documentation)	empty_function() {}	Missing keyword or command, or permission problem (and diff return code on a failed binary file comparison).
126	Command invoked cannot execute	/dev/null	Permission problem or command is not an executable
127	"command not found"	illegal_command	Possible problem with $PATH or a typo
128	Invalid argument to exit	exit 3.14159	exit takes only integer args in the range 0 - 255 (see first footnote)
128+n	Fatal error signal "n"	kill -9 $PPID of script	$? returns 137 (128 + 9)
130	Script terminated by Control-C	Ctl-C	Control-C is fatal error signal 2, (130 = 128 + 2, see above)
255*	Exit status out of range	exit -1	exit takes only integer args in the range 0 - 255

異常碼在操作系統中隨處可見，以下是一個關于 cat 進程的異常以及它的 exit code，并使用 strace 追蹤系統調用。

$ cat a 
cat: a: No such file or directory 
 
# 使用 strace 查看 cat 的系統調用 
# -e 只顯示 write 與 exit_group 的系統調用 
$ strace -e write,exit_group cat a 
write(2, "cat: ", 5cat: )                    = 5 
write(2, "a", 1a)                        = 1 
write(2, ": No such file or directory", 27: No such file or directory) = 27 
write(2, "\n", 1 
)                       = 1 
exit_group(1)                           = ? 
+++ exited with 1 +++

從 strace 追蹤進程顯示的最后一行可以看出，該進程的 exit code 是 1，并把錯誤信息輸出到 stderr (stderr 的 fd 為 2) 中

如何查看 exit code

從 strace 中可以來判斷進程的 exit code，但是不夠方便過于冗余，更無法第一時間來定位到異常碼。

有一種更為簡單的方法，通過 echo $? 來確認返回碼

$ cat a 
cat: a: No such file or directory 
 
$ echo $? 
1 
$ node -e "preocess.exit(52)" 
$ echo $? 
52

未曾感知的痛苦何在: throw new Error 與 Promise.reject 區別

以下是兩段代碼，第一段拋出一個異常，第二段 Promise.reject，兩段代碼都會如下打印出一段異常信息，那么兩者有什么區別?

function error () { 
  throw new Error('hello, error') 
} 
 
error() 
 
// Output: 
 
// /Users/shanyue/Documents/note/demo.js:2 
//   throw new Error('hello, world') 
//   ^ 
// 
// Error: hello, world 
//     at error (/Users/shanyue/Documents/note/demo.js:2:9)

async function error () { 
  return new Error('hello, error') 
} 
 
error() 
 
// Output: 
 
// (node:60356) UnhandledPromiseRejectionWarning: Error: hello, world 
//    at error (/Users/shanyue/Documents/note/demo.js:2:9) 
//    at Object.<anonymous> (/Users/shanyue/Documents/note/demo.js:5:1) 
//    at Module._compile (internal/modules/cjs/loader.js:701:30) 
//    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)

在對上述兩個測試用例使用 echo $? 查看 exit code，我們會發現 throw new Error() 的 exit code 為 1，而 Promise.reject() 的為 0。

從操作系統的角度來講，exit code 為 0 代表進程成功運行并退出，然而此時即使有 Promise.reject，操作系統也會視為它執行成功。

這在 Dockerfile 與 CI 中執行腳本時將留有安全隱患。

Dockerfile 在 Node 鏡像構建時的隱患

當使用 Dockerfile 構建鏡像或者 CI 時，如果進程返回非 0 返回碼，構建就會失敗。

這是一個淺顯易懂的含有 Promise.reject() 問題的鏡像，我們從這個鏡像來看出問題所在。

FROM node:12-alpine 
 
RUN node -e "Promise.reject('hello, world')"

構建鏡像過程如下，最后兩行提示鏡像構建成功：即使在構建過程打印出了 unhandledPromiseRejection 信息，但是鏡像仍然構建成功。

$ docker build -t demo . 
Sending build context to Docker daemon  33.28kB 
Step 1/2 : FROM node:12-alpine 
 ---> 18f4bc975732 
Step 2/2 : RUN node -e "Promise.reject('hello, world')" 
 ---> Running in 79a6d53c5aa6 
(node:1) UnhandledPromiseRejectionWarning: hello, world 
(node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1) 
(node:1) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. 
Removing intermediate container 79a6d53c5aa6 
 ---> 09f07eb993fe 
Successfully built 09f07eb993fe 
Successfully tagged demo:latest

但如果是在 node 15 鏡像內，鏡像會構建失敗，至于原因以下再說。

FROM node:15-alpine 
 
RUN node -e "Promise.reject('hello, world')"

$ docker build -t demo . 
Sending build context to Docker daemon  2.048kB 
Step 1/2 : FROM node:15-alpine 
 ---> 8bf655e9f9b2 
Step 2/2 : RUN node -e "Promise.reject('hello, world')" 
 ---> Running in 4573ed5d5b08 
node:internal/process/promises:245 
          triggerUncaughtException(err, true /* fromPromise */); 
          ^ 
 
[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "hello, world".] { 
  code: 'ERR_UNHANDLED_REJECTION' 
} 
The command '/bin/sh -c node -e "Promise.reject('hello, world')"' returned a non-zero code: 1

Promise.reject 腳本解決方案

能在編譯時能發現的問題，絕不要放在運行時。所以，構建鏡像或 CI 中需要執行 node 腳本時，對異常處理需要手動指定 process.exitCode = 1 來提前暴露問題

runScript().catch(() => { 
  process.exitCode = 1 
})

在構建鏡像時，Node 也有關于異常解決方案的建議：

runScript().catch(() => { 
  process.exitCode = 1 
})

根據提示，--unhandled-rejections=strict 將會把 Promise.reject 的退出碼設置為 1，并在將來的 node 版本中修正 Promise 異常退出碼。

而下一個版本 Node 15.0 已把 unhandled-rejections 視為異常并返回非 0 退出碼。

$ node --unhandled-rejections=strict error.js

Signal

在外部，如何殺死一個進程?答：kill $pid

而更為準確的來說，一個 kill 命令用以向一個進程發送 signal，而非殺死進程。大概是殺進程的人多了，就變成了 kill。

The kill utility sends a signal to the processes specified by the pid operands.

每一個 signal 由數字表示，signal 列表可由 kill -l 打印

# 列出所有的 signal 
$ kill -l 
 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP 
 6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1 
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM 
16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP 
21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ 
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR 
31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3 
38) SIGRTMIN+4  39) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8 
43) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7 
58) SIGRTMAX-6  59) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2 
63) SIGRTMAX-1  64) SIGRTMAX

這些信號中與終端進程接觸最多的為以下幾個，其中 SIGTERM 為 kill 默認發送信號，SIGKILL 為強制殺進程信號

信號	數字	是否可捕獲	描述
SIGINT	2	可捕獲	Ctrl+C 中斷進程
SIGQUIT	3	可捕獲	Ctrl+D 中斷進程
SIGKILL	9	不可捕獲	強制中斷進程（無法阻塞）
SIGTERM	15	可捕獲	優雅終止進程（默認信號）
SIGSTOP	19	不可捕獲	優雅終止進程中

在 Node 中，process.on 可以監聽到可捕獲的退出信號而不退出。以下示例監聽到 SIGINT 與 SIGTERM 信號，SIGKILL 無法被監聽，setTimeout 保證程序不會退出

console.log(`Pid: ${process.pid}`) 
 
process.on('SIGINT',  () => console.log('Received: SIGINT')) 
// process.on('SIGKILL', () => console.log('Received: SIGKILL')) 
process.on('SIGTERM', () => console.log('Received: SIGTERM')) 
 
setTimeout(() => {}, 1000000)

運行腳本，啟動進程，可以看到該進程的 pid，使用 kill -2 97864 發送信號，進程接收到信號并未退出

$ node signal.js 
Pid: 97864 
Received: SIGTERM 
Received: SIGTERM 
Received: SIGTERM 
Received: SIGINT 
Received: SIGINT 
Received: SIGINT

容器中退出時的優雅處理

當在 k8s 容器服務升級時需要關閉過期 Pod 時，會向容器的主進程(PID 1)發送一個 SIGTERM 的信號，并預留 30s 善后。如果容器在 30s 后還沒有退出，那么 k8s 會繼續發送一個 SIGKILL 信號。如果古時皇帝白綾賜死，教你體面。

其實不僅僅是容器，CI 中腳本也要優雅處理進程的退出。

當接收到 SIGTERM/SIGINT 信號時，預留一分鐘時間做未做完的事情。

async function gracefulClose(signal) { 
  await new Promise(resolve => { 
    setTimout(resolve, 60000) 
  }) 
 
  process.exit() 
} 
 
process.on('SIGINT',  gracefulClose) 
process.on('SIGTERM', gracefulClose)

這個給腳本預留時間是比較正確的做法，但是如果是一個服務有源源不斷的請求過來呢?那就由服務主動關閉吧，調用 server.close() 結束服務

const server = http.createServer(handler) 
 
function gracefulClose(signal) { 
  server.close(() => { 
    process.exit() 
  }) 
} 
 
process.on('SIGINT',  gracefulClose) 
process.on('SIGTERM', gracefulClose)

總結

當進程結束的 exit code 為非 0 時，系統會認為該進程執行失敗
通過 echo $? 可查看終端上一進程的 exit code
Node 中 Promise.reject 時 exit code 為 0
Node 中可以通過 process.exitCode = 1 顯式設置 exit code
在 Node12+ 中可以通過 node --unhandled-rejections=strict error.js 執行腳本，視 Promise.reject 的 exit code 為 1，在 Node15 中修復了這一個問題
Node 進程退出時需要優雅退出
k8s 關閉 POD 時先發一個 SIGTERM 信號，留 30s 時間處理未完成的事，如若 POD 沒有正常退出，30s 過后發送 SIGKILL 信號

參考資料

[1]

Appendix E. Exit Codes With Special Meanings: http://www.tldp.org/LDP/abs/html/exitcodes.html

責任編輯：武曉燕來源：全棧成長之路

Node 進程 Cron