嗯,这是山月好久没有更新的原创,正文从下开始。

人固有一死,一个 Node 进程亦是如此,总有万般不愿也无法避免。从本篇文章我们看看一个进程灭亡时如何从容离去。

一个 Node 进程,除了提供 HTTP 服务外,也绝少不了跑脚本的身影。跑一个脚本拉取配置、处理数据以及定时任务更是家常便饭。在一些重要流程中能够看到脚本的身影:

  1. CI,用以测试、质量保障及部署等

  2. Cron,用以定时任务

  3. 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 ErrorPromise.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,操作系统也会视为它执行成功。

这在 DockerfileCI 中执行脚本时将留有安全隐患。

Dockerfile 在 Node 镜像构建时的隐患

当使用 Dockerfile 构建镜像或者 CI 时,如果进程返回非 0 返回码,构建就会失败。

这是一个浅显易懂的含有 Promise.reject() 问题的镜像,我们从这个镜像来看出问题所在。

FROM node:12-alpineRUN 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-alpineRUN 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:245triggerUncaughtException(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 也有关于异常解决方案的建议:

(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)

根据提示,--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 -l1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP6) 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)

总结

  1. 当进程结束的 exit code 为非 0 时,系统会认为该进程执行失败

  2. 通过 echo $? 可查看终端上一进程的 exit code

  3. Node 中 Promise.reject 时 exit code 为 0

  4. Node 中可以通过 process.exitCode = 1 显式设置 exit code

  5. 在 Node12+ 中可以通过 node --unhandled-rejections=strict error.js 执行脚本,视 Promise.rejectexit code 为 1,在 Node15 中修复了这一个问题

  6. Node 进程退出时需要优雅退出

  7. k8s 关闭 POD 时先发一个 SIGTERM 信号,留 30s 时间处理未完成的事,如若 POD 没有正常退出,30s 过后发送 SIGKILL 信号

参考资料

[1]

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

- END -

最后

  • 欢迎加我微信(winty230),拉你进技术群,长期交流学习...

  • 欢迎关注「前端Q」,认真学前端,做个专业的技术人...

点个在看支持我吧

一个 Node 进程的死亡与善后相关推荐

  1. docker build命令详解_Docker 搭建你的第一个 Node 项目到服务器

    本文你能学到什么 Docker 是什么 Docker 概念 关于 Docker 的概念是确实不太好总结,下面我通过四点向你说明 Docker 到底是个什么东西. Docker 是世界领先的软件容器平台 ...

  2. node进程cpu 100%问题排查

    案情描述 现象:监控系统显示,官网的服务每个月总有那么几天会烧脑,单台服务器qps 20以内的前提下,从某一刻开始,node进程持续性消耗cpu100%,并且在剔除流量后,居高不下. 问题:cpu持续 ...

  3. 从源码解析-Android中Zygote进程是如何fork一个APP进程的

    zygote进程fork子进程 前言 强烈推荐 进程创建流程 APP启动第三方应用 startActivity startService sendBroadcast ContentResolver.q ...

  4. linux 查看进程死亡原因,【进程管理】进程的死亡

    ARM Linux 源码分析系列文章基于 Linux 2.6.22 讲解,转载请标明原处! 一个进程可以使用exit系统调用来结束自己并进入僵死状态.他最后在内核中执行到的函数为sys_exit(). ...

  5. linux搭建一个的过程,Linux内核创建一个新进程的过程

    此文仅用于MOOCLinux内核分析作业 task_struct数据结构 根据wiki的定义,进程是计算机中已运行程序的实体.在面向线程设计的系统(Linux 2.6及更新的版本)中,进程本身不是基本 ...

  6. 大神教你如何给脚本写一个守护进程

    在我们日常运维中,写脚本监控一个进程是比较常见的操作,比如我要监控mysql进程是否消失,如果消失就重启mysql. 用下面这段代码就可以实现: #!/bin/shDate=` date '+%c'` ...

  7. 两个EdgeNode夹一个Node

    在C中,各种类型的指针本身只是一个地址值,长度都是一样的.但是只知道地址值,你是没法确定往后多少bit是你真正有效的数据范围,所以指针就要加类型来确定往后取得范围. 所以你的struct里面那个嵌套的 ...

  8. 另一个git进程似乎在这个存储库中运行

    我正在尝试学习如何使用Git,并创建了一个包含HTML,CSS和Javascript文件的小项目. 我从我的基本空项目中创建了一个分支,然后对我的代码进行了一些更改. 我尝试暂存更改,但我收到以下错误 ...

  9. flask使用debug模式时,存在错误时,会占用设备内存直至服务重启才释放;debug模式会开启一个守护进程(daemon process)...

    函数调用顺序flask的app.py的run-->werkzeug的serving.py的run_simple-->调用werkzeug的debug的__init__.py里的类Debug ...

最新文章

  1. 车联网空间巨大 解决网络安全问题乃当务之急
  2. 计算机背小学英语吗,小学英语课本点读电脑版
  3. 【计算机网络】网络安全 : 实体鉴别 ( 实体鉴别过程 | 不重数机制 | 公钥体质加密不重数 | 中间人攻击 )
  4. 关于【C++项目:无法解析的外部符号】
  5. USACO翻译:USACO 2012 JAN三题(3)
  6. 小学计算机ppt课教案,小学信息技术公开课教案《让幻灯片变得更加漂亮》教学设计与反思...
  7. CPU、GPU、FPGA、ASIC等AI芯片特性及对比
  8. python鼠标选中事件_python对绑定事件的鼠标、按键的判断实例
  9. 基于Android 9.0 电池温度异常提醒
  10. 【原创】Nginx+PHP-FPM优化技巧总结
  11. python慢的原因_为什么 Python 这么慢?
  12. python 打开txt_python编程之文件操作
  13. 【Scala】镜像网站下载,速度直接起飞
  14. ensp VRRP配置2
  15. 计算机截屏无法保存,win7电脑自带截图软件保存图片失败怎么办?
  16. FRP内网穿透搭建-无公网IP时外部访问服务解决办法
  17. 全国DNS服务器IP地址大全、公共DNS大全
  18. 【警告】扣扣热键你了解多少
  19. VMware14安装windows7的详细过程
  20. steam好玩的免费游戏

热门文章

  1. GitHub如何配置SSH Key
  2. Ubuntu安装Madagascar
  3. 2_31_HTML的标签及列表_190910
  4. 【微电网优化】基于matlab粒子群算法求解热电联供型微电网经济运行优化问题【含Matlab源码 1696期】
  5. C++ vector中删除元素
  6. 测试2k显示器的软件,高性价比的27吋2K显示器 AOC Q27P1U评测
  7. MySQL数据库常用基本语句及管理
  8. 写一个辨别素数的函数,在主函数输入一个整数,输出是否为素数信息。
  9. 这是一个最好的时代,也是一个最坏的时代 ?
  10. 2016年8月10日 星期三 --出埃及记 Exodus 16:10