凌晨2点47分，你的WebApp又挂了。监控告警炸响，你从床上爬起来SSH登录，手动重启服务——这个月第几次了？
有个老工具能把这套流程压缩成5秒。它叫Supervisor，2004年诞生，比Docker还早9年，至今仍在无数生产环境值班。
Supervisor不是守护进程本身，而是"制造守护进程"的工厂。它像机场塔台：飞机（你的应用）起降它不管，但飞机要是坠毁，它会立刻调一架新的顶上。
装完即走：一条命令解决依赖
Debian/Ubuntu系直接apt：
apt install supervisor
装完自动注册为系统服务，开机自启。没有复杂的二进制下载，没有版本冲突，包管理器帮你兜底。
核心组件就两个：supervisord（后台主进程）和supervisorctl（命令行遥控器）。前者盯梢，后者让你随时查状态、启停服务。
配置解剖：6行代码定义"自愈"规则
假设你的WebApp已编译好，先丢进系统目录：
cp WebApp /usr/local/bin/
然后写配置文件，路径固定为/etc/supervisor/conf.d/webapp.conf：
[program:webapp] command=/usr/local/bin/webapp user=www-data autostart=true autorestart=true
关键就最后两行：autostart=true让机器开机自动跑，autorestart=true让崩溃自动复活。user=www-data降权运行，避免应用被攻破后拿到root。
日志配置同样重要。stdout_logfile和stderr_logfile分开存，各50MB上限、保留3个轮替文件。既防磁盘爆满，又方便事后翻案。
生效流程：reread和update的区别
改完配置别急着重启，Supervisor有热加载机制：
supervisorctl reread —— 只扫描文件变化，不碰运行中的进程 supervisorctl update —— 真正应用变更，新增/删除/重载配置
两步分开的设计很产品经理思维：reread让你预览改动，确认无误再update。线上环境改崩过配置的人都懂这有多救命。
最后启动：supervisorctl start webapp，查状态：supervisorctl status webapp。输出格式跟systemctl几乎一样，迁移成本极低。
Supervisor和systemctl不是二选一。前者管应用层保活，后者管系统级服务。很多团队两者混用：Nginx走systemctl，自研WebApp走Supervisor，崩溃重启策略更灵活。
有个细节很多人踩坑：Supervisor监控的是进程PID，如果你的应用fork出子进程后父进程退出，Supervisor会误判为"已停止"然后疯狂重启。解决方法是配置startsecs=10，给足启动缓冲期。
另一个隐藏技能是进程组（group）。把API服务、队列消费者、定时任务写进同一个group，可以一键启停整组服务，部署时特别顺手。
2019年Supervisor 4.0终于支持Python 3，社区一度以为项目已死。但它就像那些老旧的机场塔台系统——不好看，不时髦，但航班（你的服务）从来没掉下来过。
你的生产环境还在用手动重启吗？还是已经上了Kubernetes这类重型方案，却为了一个小脚本也要写20行YAML？
热门跟贴