Linux配置Supervisord实现进程自动重启

Supervisord 能够实现进程的自动重启，但前提是进程必须以前台方式运行，不能是守护进程（daemon）。如果直接使用 nohup ./app & 这类后台启动方式，Supervisord 将无法监控到进程状态。

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 环境，干净利落地正常运行。