pm2进程终止后能自动重启吗？

Question

当使用 PM2 管理 Node.js 应用时，若进程因未捕获异常或系统信号被强制终止，PM2 是否能自动重启该进程？常见问题在于：尽管 PM2 默认启用 `restart` 策略，但在某些情况下（如 OOM 被系统 kill、手动执行 `kill -9` 或服务器资源耗尽），进程退出后未能如期重启。这是否与 PM2 的 `autorestart: true` 配置冲突？如何确保在各种异常场景下 PM2 仍能可靠地自动拉起应用？需排查日志、配置及系统资源限制等因素。

Answer 1

PM2 自动重启机制深度解析：从基础到高可用保障

1. PM2 基础重启机制概述

PM2 是 Node.js 生态中最流行的进程管理工具之一，其核心功能之一是 自动重启（autorestart）。默认情况下，PM2 配置中 autorestart: true，意味着当应用因未捕获异常、代码错误或正常退出码非0时，PM2 会尝试重新拉起进程。

PM2 监听子进程的退出信号，并根据退出码决定是否重启：

• 退出码 0：正常退出，不重启（除非配置了 restart_delay 或定时策略）
• 退出码非 0：异常退出，触发重启逻辑
• SIGTERM, SIGINT：可被捕获，若未处理则视为异常退出

然而，在某些极端场景下，即使配置了 autorestart: true，PM2 也无法感知进程状态，导致无法重启。

2. 异常终止场景分析与 PM2 的响应能力

并非所有进程终止都能被 PM2 捕获。以下为常见异常场景及其对 PM2 重启机制的影响：

终止原因	信号类型	PM2 是否能捕获	是否触发 autorestart	备注
未捕获异常（uncaughtException）	无显式信号	是	是	Node.js 进程崩溃，PM2 可检测
Promise 未处理拒绝	unhandledRejection	是	是	Node.js v15+ 默认终止进程
系统 OOM Killer 终止	SIGKILL (9)	否	否	内核直接杀死，PM2 无感知
手动 kill -9 <pid>	SIGKILL	否	否	强制杀进程，绕过用户空间监控
内存耗尽导致系统冻结	无信号	部分情况失效	否	PM2 主进程也可能卡死
磁盘满/文件描述符耗尽	无直接信号	依赖应用行为	视情况而定	可能引发不可预测崩溃

3. 为什么 autorestart: true 在某些场景下“失效”？

表面上看，autorestart: true 似乎应保证任何退出后都重启，但实际上该配置仅在 PM2 能感知到进程退出事件时生效。关键点在于：

1. SIGKILL（信号 9）不可被捕获或忽略，操作系统内核直接终止进程，不通知用户空间程序（包括 PM2）。
2. 当系统因 OOM 触发 oom_killer 时，优先杀死占用内存最多的进程，且使用 SIGKILL，PM2 子进程被杀但主守护进程可能仍在运行，却无法得知子进程已消失。
3. 服务器资源极度紧张（如 CPU 100%、swap 耗尽）可能导致 PM2 主进程调度延迟，无法及时响应监控事件。

因此，这并非与 autorestart: true 配置冲突，而是超出了 PM2 的监控边界。

4. 排查流程与诊断方法

当发现应用未重启时，应按以下流程排查：

# 查看 PM2 进程列表及状态
pm2 list

# 检查特定应用日志（重点关注退出前最后输出）
pm2 logs app_name --lines 100

# 查看 PM2 内部日志（位于 ~/.pm2/pm2.log）
tail -f ~/.pm2/pm2.log

# 检查系统级日志是否发生 OOM
dmesg | grep -i 'oom\|kill'

# 查看系统资源使用情况
free -h
df -h
ulimit -a

5. 提升 PM2 高可用性的解决方案

为确保在各类异常场景下仍能恢复服务，需采取多层次防护策略：

• 启用 PM2 的 max_memory_restart：设置内存阈值自动重启，防止缓慢内存泄漏导致 OOM。

  {
    "name": "my-app",
    "script": "app.js",
    "max_memory_restart": "500M"
  }

• 配置系统级监控脚本：通过 cron 或 systemd 定期检查 PM2 状态，必要时重启 PM2 守护进程本身。
• 使用外部健康检查 + 进程存活探测：结合 Nagios、Prometheus 或自定义脚本轮询应用端口，并在失联时执行恢复命令。
• 限制应用资源使用：通过 cgroups 或 systemd 控制内存上限，避免单个应用拖垮整机。

6. 架构级容灾设计：超越 PM2 的局限

PM2 本质是一个单机进程管理器，无法解决主机级故障。生产环境建议采用如下架构增强可靠性：

graph TD A[客户端] --> B[Nginx 负载均衡] B --> C[PM2 实例 1
Server A] B --> D[PM2 实例 2
Server A] B --> E[PM2 实例 1
Server B] B --> F[PM2 实例 2
Server B] G[监控系统] -->|健康检查| B H[告警平台] -->|异常通知| I[(运维人员)] J[Docker/Kubernetes] -->|容器编排| C & D & E & F

通过部署多节点集群、引入负载均衡与外部编排系统（如 Kubernetes），可实现跨主机容灾，弥补 PM2 单点监控盲区。