Supervisor实战：从爬虫崩溃到自动重启的进程守护指南

写爬虫的人都有过这种经历：本地调试的时候跑得顺顺当当，一旦放到服务器上，就变成了“薛定谔的进程”——你不知道它现在是活着还是已经挂了，反正 SSH 一关，第二天再登录，ps aux 里什么都找不到。更头疼的是，服务器偶尔重启一次，所有手工启动的爬虫全部归零，又要一台一台重新拉起来。我最早折腾“爬虫部署”的时候也被这个问题折磨得不轻，后来接触了 Supervisor，才算把这块短板补上。

Supervisor 本质上是一个进程守护和管理工具，它的核心价值用大白话说就是：让你不用再手动去维护那些后台常驻的 Python 爬虫进程。不管是崩溃自动重启、开机自启、日志统一管理，还是同时控制几十个爬虫实例，它都可以比较优雅地搞定。这篇文章我会把 Supervisor 从安装、配置、启动到踩坑排错整个链路讲透，重点贴合爬虫部署场景，适合刚接触服务器运维、打算把自己的爬虫脚本真正“产品化”的开发者参考。

1. 爬虫进程“裸跑”有多疼：为什么需要 Supervisor

1.1 SSH 一关进程就没了，这个问题怎么解的

很多人的第一版爬虫部署流程是这样的：本地写好脚本，丢到服务器上，执行 python spider.py，看到日志开始滚动，觉得大功告成。然后断开 SSH，过一会儿再登进去，发现进程已经没了。原因很简单——直接在终端里运行的进程，会跟随当前终端会话的生命周期，终端关闭时 shell 会向进程组发送挂断信号，进程默认就会退出。

为了解决这个问题，大概率会尝试几种方案。第一种是用 nohup python spider.py &，把进程放到后台并忽略挂断信号。“nohup”这个名字其实就是“no hang up”的缩写，这在早期确实解决了一部分问题，但缺陷也很明显：进程意外崩溃了没人管，它不会自动重新拉起来；服务器重启了，这堆后台进程也不会主动恢复，还是得手动登录操作。第二种是用 screen 或 tmux，开一个守护窗口在里面跑，这样 SSH 断了窗口还在。但严格说这只是“伪后台”，窗口里的进程依然依赖那个会话环境，而且一旦窗口被误删，进程一样逃不掉。

这些方案的共同问题是：它们只是把进程“挂”在了某个地方，并没有对进程做真正的生命周期管理。而真正部署在服务器上长期运行的爬虫，需要的是一套“进程管家”，能盯着进程状态、能自动重启、能统一收集日志——这些恰恰是 Supervisor 的看家本领。

1.2 崩溃重启、开机自启、日志管理：Supervisor 要做的事

具体到爬虫场景，Supervisor 帮我解决的实际问题可以列成这几点：

• 崩溃自动重启：爬虫跑久了难免会遇到网络超时、目标站点返回异常、内存溢出之类的问题，进程一旦崩掉，Supervisor 会在几秒内把它重新拉起来，不需要人工干预。对于需要 7x24 小时不间断采集的任务来说，这是最核心的需求。
• 开机能自启：配置了 autostart=true 的进程，会跟随 supervisord 服务一起启动。也就是说，只要服务器重新开机，supervisord 起来了，爬虫也会自动恢复，不用再手动登录服务器执行启动命令。
• 日志统一管理：每个被托管的进程，标准输出和错误输出都可以分别写到指定文件，还能按大小自动切割。排查问题的时候，直接打开统一目录下的日志文件，不用满服务器找 nohup.out。
• 统一操作多进程：用一条命令可以同时启动、停止、重启一组爬虫，不用一个个去 ps 找 PID 再 kill。

这就是 Supervisor 在爬虫部署里的定位。它不是一个“跑爬虫”的工具，而是一个“管爬虫”的工具。

1.3 和 systemd、screen、nohup 的对比，为什么选 Supervisor

既然提到了进程守护，可能很多人会问：现在 Linux 上不是有 systemd 吗？为什么还要单独用 Supervisor？

systemd 确实可以做进程守护，但它的定位是系统级服务管理，配置起来比较重，而且每次修改配置都要重新加载 service 文件，规则相对繁琐。对一个经常要调整启动参数、会频繁新增爬虫实例的爬虫项目来说，Supervisor 更轻量、更灵活：

• 修改配置后执行 supervisorctl update 就能热加载，不需要重启整个服务。
• 新增一个爬虫，只需要在 conf.d 目录里丢一个 .conf 文件，再 reread 和 update。
• 支持进程分组管理，对多爬虫项目的操作效率明显更高。

至于 screen / tmux，它们更适合交互式使用，不是为无人值守的长期进程设计的。nohup 则连“崩溃重启”和“开机自启”都做不到。所以从爬虫部署的长远角度来看，Supervisor 是综合成本和效率都比较理想的选择。

2. Supervisor 的体系结构：两个进程、一份配置和一个命令

2.1 supervisord 与 supervisorctl：服务端和客户端的配合

刚开始用 Supervisor 的时候，我一度搞不清楚 supervisord 和 supervisorctl 的关系。其实它们的关系很像 MySQL 的服务端和客户端：supervisord 是常驻后台的主进程，负责启动、停止、监控所有被托管的子进程；supervisorctl 是你敲命令用的客户端工具，通过它向 supervisord 发指令，比如查询状态、启停进程、查看日志。

我建议把 supervisord 理解成一个“进程托管中心”，你的爬虫进程全都挂在它下面。它启动之后不会退出，一直蹲在后台盯着状态。supervisorctl 则是你用来管理这些进程的“遥控器”。在命令行输入 supervisorctl status