Linux怎么配置Supervisord管理进程 Linux后台任务自动重启详解

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 环境，干净利落地跑起来。