这个场景解决什么
supervisor 托管的进程重启之后立刻退出，日志里反复出现启动失败。这时不该继续无脑 restart，而应按顺序看三件事：它自己的标准错误输出与退出码、配置里的命令与运行用户、以及按同样条件手工执行一次能否成功。多数问题最终都落在路径、环境变量与工作目录上。
基本信息
| 场景 | supervisor 托管的进程起不来或启动后秒退 |
|---|---|
| 组合方式 | status 查看 + tail 看输出 + 手工复现 |
| 关键配置项 | command、user、directory、environment |
| 日志位置 | supervisord 自身日志与程序的标准错误输出 |
典型使用场景
- 服务发布后进程反复退出，需要定位根因
- 更换运行用户之后突然起不来
- 相对路径在新环境里失效导致启动失败
- 环境变量缺失导致找不到命令或模块
- 启动脚本改为前台运行后行为发生变化
- 排查 STARTING 状态长时间卡住不动
看现场与手工复现
看现场与手工复现
supervisorctl status # 看状态与最近一次退出信息
supervisorctl tail app-worker stderr # 查看错误输出
tail -n 50 /var/log/supervisor/app-worker-stderr*.log
grep -E 'command|user|directory|environment' /etc/supervisord.d/app-worker.ini
sudo -u www-data bash -lc 'cd /opt/app && ./run.sh' # 按配置条件手工跑一次
systemctl status supervisord --no-pager | head # 确认守护进程状态
supervisorctl reread && supervisorctl update # 让改动真正生效排查顺序
| 步骤 | 动作 | 目的 |
|---|---|---|
| 一 | 看 status 与最近退出信息 | 区分退出与启动失败 |
| 二 | 看标准错误与日志文件 | 拿到真实报错 |
| 三 | 核对 command 与 user | 确认参数与身份符合预期 |
| 四 | 按配置条件手工执行一次 | 区分配置问题与程序问题 |
| 五 | reread 与 update | 让改动真正生效 |
supervisor 不加载登录 shell 的环境：找不到命令或模块的报错，多半是 PATH 与虚拟环境变量缺失，配置里用绝对路径或 environment= 显式声明即可解决。
改完 ini 必须执行 reread 再 update，否则运行的还是旧配置；反复 restart 只是让同一个问题再出现一次，日志越刷越多。
STARTING 状态长时间不动，通常是 startsecs 与进程实际启动耗时不匹配，或者程序实际在前台运行却被当成后台程序处理。
如果程序本身是前台运行的脚本，配置里的命令不要用 & 或 nohup 让它自行后台化：supervisor 需要直接持有主进程，否则会立刻判定进程已退出。