Supervisor虽被systemd取代，但在容器或无root环境仍有用；常见问题包括：nodaemon=true致前台退出、日志路径不可写、socket权限错、配置未reread/update、command非绝对路径、startsecs过短致误判崩溃、autorestart=unexpected防误重启、redirect_stderr确保日志可见。
Supervisor 在现代 Linux 服务管理中已基本被 systemd 取代，新系统直接用 systemd 写 service 文件更轻量、更可靠；但如果你必须用 Supervisor（比如旧项目依赖、容器内无 root 权限、或需要统一管理非 systemd 环境下的 Python/Node 进程），它仍能工作——只是得避开几个典型陷阱。
为什么 supervisord 启动后立刻退出？
常见现象：supervisord -c /etc/supervisord.conf 执行完没报错，但进程没了，ps aux | grep supervisord 查不到。
-
supervisord默认以 daemon 模式运行，但若配置里daemon=false（或未显式设为true），它会前台启动后立即退出——尤其在 Docker 或非交互终端里 - 检查
supervisord.conf是否含nodaemon=true：这是调试时的临时设置，生产环境必须删掉或设为false - 日志路径不可写也会导致静默失败，确认
logfile=/var/log/supervisor/supervisord.log对应目录存在且属主为运行用户（如root或supervisor） - 若用非 root 用户启动，
supervisorctl默认连的是/tmp/supervisor.sock，而该 socket 路径权限可能不匹配，建议显式配置unix_http_server的file和chmod
supervisorctl start xxx 报错 “ERROR (no such process)”
不是程序没写对，而是配置没加载成功——Supervisor 不自动重载 conf 文件。
- 新增或修改了
/etc/supervisor/conf.d/*.conf后，必须手动执行supervisorctl reread（重新扫描配置）→supervisorctl update（应用变更） - 确认你的 program 配置文件名以
.conf结尾，且放在include指向的目录下（例如files = /etc/supervisor/conf.d/*.conf） -
command值必须是绝对路径，比如command=/usr/local/bin/gunicorn ...，不能写command=gunicorn ...（它不读$PATH） - 如果用
environment=PATH="/usr/local/bin:/usr/bin"，注意等号两边不能有空格，且值要用双引号包裹
Python Web 应用反复重启，startsecs 和 autorestart 怎么配？
根本问题不在参数本身，而在进程是否真“启动完成”。Supervisor 判断“启动成功”的唯一依据是进程进入运行态 + 稳定存活满 startsecs 秒。
- Web 服务（如 Flask/Gunicorn）常需几秒预热（加载模型、连 DB），若
startsecs=1，它刚 fork 出子进程就判定失败，触发无限重启 - 推荐设
startsecs=10，并配合startretries=3（避免因 DB 暂不可用就永久失败） -
autorestart=unexpected是关键：只在非正常退出（如 crash、信号 kill）时重启；若设为true，哪怕你手动supervisorctl stop xxx，它也会立刻拉起 - 务必加
redirect_stderr=true和stdout_logfile=/var/log/myapp.log，否则看不到启动日志，无法判断是卡在哪儿
Supervisor 的核心限制在于：它不感知进程内部状态，只看 OS 进程生命周期。一旦你的程序 fork 多次（比如 Gunicorn 的 pre-fork 模式）、或用 exec 替换自身，Supervisor 就可能跟丢主进程。这种情况下，宁可退回到 systemd 的 Type=simple 或 Type=forking，也别强行套 Supervisor。
