迁移至Amazon Linux 2023后PM2服务异常的自动恢复方法咨询

看起来你在从Amazon Linux 2迁移到Amazon Linux 2023时遇到了PM2服务的棘手问题——明明通过dump文件恢复后服务显示online，但实际根本没运行，CPU内存都没占用，Apache代理也连不上，手动启动虽然可行但想找更高效的自动恢复办法对吧？我来给你梳理几个靠谱的排查和解决方案：

先排查dump文件的兼容性问题 #

Amazon Linux 2023和Amazon Linux 2的环境（比如Node版本、系统依赖、路径权限）可能存在隐性差异，直接复制旧机器的dump.pm2很容易出问题：

• 检查服务路径一致性：执行 pm2 show <服务名称>，查看输出里的cwd（工作目录）和script字段，确认是否和新机器上的实际文件路径完全匹配。如果路径不对应，PM2就算触发启动命令也找不到脚本，自然不会产生实际运行的进程。
• 查看启动日志：PM2的状态列表可能不会直接显示启动失败的原因，执行pm2 logs <服务名称>，说不定能看到具体报错——比如依赖缺失、Node版本兼容问题、语法错误等，这些都会导致服务看似online实则未运行。

修复dump文件后重新自动恢复 #

如果确认是路径或环境配置问题，不用手动逐个启动，我们可以修复dump文件后再执行自动恢复：

1. 先备份当前dump文件：cp /root/.pm2/dump.pm2 /root/.pm2/dump.pm2.bak
2. 编辑dump文件（它是JSON格式）：nano /root/.pm2/dump.pm2，把里面所有旧机器的路径替换为新机器的对应路径，同时检查env字段里的环境变量是否适配新系统。
3. 停掉当前所有PM2进程：pm2 delete all
4. 重新执行恢复命令：pm2 resurrect
5. 最后用pm2 status和pm2 logs确认服务是否真正在运行。

用PM2生态配置文件实现可靠自动管理 #

如果dump文件的兼容性问题反复出现，不如直接生成适配新系统的PM2生态配置文件，这样后续的自动恢复会更稳定：

1. 若能操作旧机器，直接导出生态配置：pm2 ecosystem；如果旧机器无法访问，就在新机器上手动创建ecosystem.config.js，把7个服务的配置依次写入，示例格式如下：

module.exports = {
  apps : [{
    name: 'IDAP Dev',
    script: './app.js',
    cwd: '/path/to/your/project/dir',
    env: {
      NODE_ENV: 'development'
    }
  },
  // 其他6个服务的配置按同样格式添加
  ]
};

2. 用配置文件启动所有服务：pm2 start ecosystem.config.js
3. 保存当前状态为新的dump文件：pm2 save，这样后续执行pm2 resurrect就能自动恢复适配新系统的服务配置了。
4. 最后重新生成PM2的systemd服务配置：pm2 startup systemd -u root --hp /root，执行systemctl restart pm2-root，确保系统重启后也能自动拉起所有服务。

额外检查权限问题 #

Amazon Linux 2023的权限机制可能和AL2有所不同，要确保PM2运行的用户（这里是root）对项目目录、Node脚本拥有读写执行权限。如果项目文件是从旧机器复制过来的，可能权限位异常，可执行以下命令修复：

chown -R root:root /path/to/your/all/projects
chmod -R 755 /path/to/your/all/projects

备注：内容来源于stack exchange，提问作者philolegein