Node 进程的死亡与善后

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

人固有一死，一个 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]。

上述两个测试用例使用 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() 问题的镜像，我

（编辑：通化站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!