Supervisord 要求被托管程序前台运行且非 daemon，配置需手动初始化（如 echo_supervisord_conf > /etc/supervisord.conf），autorestart 失效常见于前台启动失败、权限不足、环境变量缺失或日志路径不可写。
Supervisord 能让进程自动重启，但前提是它必须是前台运行的非 daemon 程序；直接丢一个 nohup ./app & 进去，它根本监控不到。
supervisord 启动失败或找不到配置文件
安装后不生成默认配置是常见问题——supervisord 不会自动创建 /etc/supervisord.conf，得手动初始化：
- 运行
echo_supervisord_conf > /etc/supervisord.conf生成基础配置 - 检查
[include]段是否启用，且路径存在（如files=/etc/supervisord.d/*.ini） -
/etc/supervisord.d/目录必须手动创建，否则supervisorctl reread会静默忽略 - 启动时务必指定配置：
supervisord -c /etc/supervisord.conf，否则它可能读$CWD/supervisord.conf或报unix://tmp/supervisor.sock no such file
program 配置里 autorestart=true 不生效
表面开了自动重启，实际崩溃后没拉起，通常卡在这几个点：
-
command启动的程序必须前台运行：比如nginx得加daemon off;，gunicorn加--daemon=false，python app.py别写成python -m daemon app.py -
startsecs设太小（如1），程序刚吐完日志就退出，supervisord 认为“启动失败”，反复重试直到startretries耗尽才放弃 - 权限问题：
user指定的用户对command路径、directory或日志目录无读/执行/写权限，supervisorctl status显示STARTING卡住不动 - 环境变量缺失：用
environment=PATH="/usr/local/bin:/usr/bin",HOME="/home/app"补全，别依赖 shell 的$PATH
日志写不进 stdout_logfile 或报 Permission denied
supervisord 以配置里的 user 身份写日志，不是 root —— 这是最容易被忽略的权限陷阱：
- 确保日志路径父目录存在且可写：
mkdir -p /var/log/myapp && chown app:app /var/log/myapp - 别把日志写到
/tmp或/root下，这些位置普通用户写不了 -
stdout_logfile_maxbytes和stdout_logfile_backups要配对设，否则轮转失败后日志停止写入 - 如果
redirect_stderr=true，错误不会单独写进stderr_logfile，全合并到stdout_logfile里了
supervisorctl status 显示 FATAL 或 BACKOFF
这不是配置错，而是 supervisord 已经在尝试拉起但持续失败：
-
FATAL：配置语法错误，或command路径根本不存在（bash: /xxx/app: No such file or directory） -
BACKOFF：启动失败后按指数退避重试（如 1s→3s→9s），说明程序启动了但立刻退出；重点查stdout_logfile最后几行，看是不是缺库、端口被占、配置文件路径错 -
STOPPED不代表挂了，只是你手动stop过；RUNNING才真在跑；STARTING卡住超过startsecs秒，大概率是权限或路径问题 - 调试时先关掉
autorestart，用supervisorctl start xxx手动触发一次，再立刻tail -f日志，比盲等自动重启快得多
真正难调的永远不是“怎么写配置”，而是确认那个被托管的程序——它真的能在 supervisord 的用户身份下，不依赖交互、不后台化、不依赖 shell 环境，干净利落地跑起来。
