AWS ElasticBeanstalk集成PM2实现服务自动重启遇进程状态错误求助

问题场景 #

• 核心目标：在AWS ElasticBeanstalk运行环境中集成PM2，实现服务异常停止后的自动重启能力
• 前置操作：参照PM2官方AWS ElasticBeanstalk集成教程完成全流程配置，当前服务预设为no-daemon模式运行
• 异常表现：通过SSH登录对应EC2实例手动启动PM2后，执行pm2 list命令查看进程状态，目标业务进程被标记为errored，伴随明确的进程启动失败报错信息

高频报错原因定位 #

排查时不要仅依赖pm2 list的状态标识，优先执行pm2 logs <目标进程ID/名称>拉取具体错误栈，多数errored状态来自以下配置冲突：

• 启动身份不匹配：EB环境默认运行应用的系统用户为webapp，若手动操作时混用root用户启动PM2进程，再切回webapp身份查询状态，会因进程权限归属不一致触发状态异常
• no-daemon模式使用场景错误：no-daemon参数是设计给EB部署阶段的平台钩子脚本调用的，若SSH登录调试时直接携带该参数手动启动PM2，会因没有后台守护进程接管，启动后立刻退出被标记为errored
• 路径/权限配置偏差：ecosystem配置文件、应用入口文件的路径权限未对webapp用户开放，或端口配置和EB默认挂载的Nginx端口存在占用冲突，都会导致进程启动失败

对应修复操作 #

• 统一操作身份：所有PM2相关操作（启动进程、保存进程列表、配置自启）都统一使用webapp用户执行，操作时可通过sudo -u webapp <pm2命令>切换身份，避免多身份混同导致的权限问题
• 调整no-daemon参数的适用范围：手动调试时不要携带--no-daemon参数启动PM2，该参数仅配置在EB的.platform/hooks/predeploy路径下的部署脚本中，由平台在部署阶段以非阻塞方式拉起PM2托管逻辑
• 清理残留错误进程：以webapp身份执行pm2 delete all清空之前启动失败的残留进程，核对ecosystem配置文件中的入口路径、启动端口和实际环境保持一致，重新执行pm2 start ecosystem.config.js启动应用
• 持久化进程配置：待进程状态变为online后，执行pm2 save将当前进程列表持久化，配合EB的supervisord托管逻辑实现实例重启后进程自动恢复

内容的提问来源于stack exchange，提问作者Rabin