Supervisor vs Systemd：系统管理员和开发者的进程管理工具选择指南

第一部分：详细介绍

1. Supervisor

• 定位： 一个纯粹的进程控制系统。它设计用于管理用户空间的应用程序进程，尤其适合于在非特权用户环境下运行（比如 Web 应用、队列工作者等）。它不管理系统级服务或启动进程。
• 核心功能：
  • 启动/停止/重启进程： 控制配置文件中定义的程序。
  • 进程监控： 持续监控其管理的进程。如果进程意外退出（崩溃），Supervisor 会自动重启它（可配置重启策略）。
  • 日志管理： 捕获进程的标准输出和标准错误，可以选择将其重定向到文件、syslog 或通过 Web UI 查看。支持日志轮转。
  • 进程组： 可以将多个相关进程组织成一个组，方便进行批量操作（启动、停止整个组）。
  • 事件通知： 当进程状态发生变化（启动、退出、失败重启等）时，可以通过配置发送邮件或其他通知。
  • 集中管理： 通过一个统一的守护进程 (supervisord) 管理所有配置的程序。
  • Web UI (可选)： 提供一个简单的基于 Web 的用户界面 (supervisorctl 的 Web 版本)，用于查看进程状态、日志、启动、停止进程等。
  • XML-RPC API： 提供编程接口，允许其他应用或脚本与 Supervisor 交互。
• 配置：
  • 主配置文件：通常是 /etc/supervisor/supervisord.conf。定义全局设置和包含其他程序配置文件的位置。
  • 程序配置文件：通常放在 /etc/supervisor/conf.d/ 目录下（.conf 或 .ini 格式）。每个文件定义一个或多个要管理的程序。配置相对简单直观。
  • 关键配置项：command (启动命令), directory (工作目录), user (运行用户), autostart (是否随 Supervisor 启动), autorestart (重启策略), stdout_logfile/stderr_logfile (日志文件路径), environment (环境变量) 等。
• 使用方式：
  • 命令行工具 supervisorctl：用于交互式或命令行方式控制进程 (start, stop, restart, status, tail, reread, update, reload 等)。
  • Web UI：通过浏览器访问 http://your-server:9001 (默认端口)。
• 优点：
  • 简单易用： 配置直观，学习曲线平缓。
  • 用户空间聚焦： 完美管理非系统级的用户应用进程。
  • 强大的进程监控与自动重启： 核心优势，确保关键应用持续运行。
  • 优秀的日志管理： 集中捕获和查看日志非常方便。
  • 轻量级： 本身占用资源少。
  • 跨平台： 基于 Python，可在多种 Unix-like 系统上运行。
  • 避免 PID 文件问题： 自身管理进程，无需依赖 PID 文件。
• 缺点：
  • 非系统级： 不管理系统启动、系统服务依赖关系、挂载点等。
  • 依赖自身守护： 如果 supervisord 本身崩溃，它管理的所有进程都会失控（虽然可以通过 init 系统或 systemd 来确保 supervisord 自身存活）。
  • 功能相对单一： 专注于进程控制，不提供资源限制、复杂的依赖解析、安全沙箱等高级特性（虽然 rlimit 等基本限制可通过配置实现）。
  • 日志非系统集成： 日志默认独立于系统日志（如 syslog/journald），需要额外配置集成。

2. Systemd

• 定位： 一个系统和服务管理器。它是现代 Linux 发行版 (RHEL/CentOS 7+, Debian 8+, Ubuntu 15.04+, Fedora 15+, Arch, openSUSE 等) 默认的 init 系统 (PID 1) 和服务管理器。它负责启动整个系统、管理系统服务、挂载文件系统、日志记录、设备管理、用户会话管理等，远不止于进程管理。
• 核心功能 (与服务管理相关的)：
  • 系统初始化： 作为 PID 1 引导系统，处理内核启动参数，启动核心系统组件。
  • 服务管理： 启动、停止、重启、重载、启用/禁用（开机自启）系统服务（.service 单元）。
  • 依赖管理： 强大的依赖关系解析 (Requires, Wants, After, Before)，确保服务按正确顺序启动。
  • 进程监控与重启： 类似 Supervisor，可以配置服务崩溃后自动重启 (Restart=, RestartSec=)。支持多种失败策略。
  • 资源控制： 通过 cgroups 提供精细化的资源限制（CPU, 内存, IO, 进程数等）和隔离 (CPUQuota=, MemoryLimit=, IOWeight= 等)。
  • 日志集成： 内置强大的日志系统 journald，集中收集来自内核、系统服务、应用程序（如果配置）的所有日志。提供 journalctl 工具进行高效查询和分析 (journalctl -u unitname)。支持日志轮转和持久化。
  • 按需启动： 基于 socket 或 bus 激活的服务，在第一个连接请求到来时才启动 (socket 单元)。
  • 挂载点管理： 管理 /etc/fstab 和自动挂载点 (mount, automount 单元)。
  • 定时任务： 替代 cron (timer 单元)。
  • 目标： 类似于 SysVinit 的运行级别 (runlevel)，但更灵活 (multi-user.target, graphical.target 等)。
  • 安全特性： 支持沙箱、命名空间隔离、能力限制 (CapabilityBoundingSet=, ProtectSystem=, PrivateTmp= 等)。
  • 用户服务： 管理每个用户会话内的服务 (systemctl --user)。
• 配置：
  • 单元文件：存储在 /usr/lib/systemd/system/ (系统默认) 和 /etc/systemd/system/ (管理员自定义和覆盖)。文件扩展名定义类型 (.service, .socket, .mount, .timer 等)。
  • 服务单元文件 (*.service)：是最常用的。结构分 [Unit], [Service], [Install] 三个部分。
    • [Unit]: 描述、依赖关系 (Requires, After)、文档链接等。
    • [Service]: 核心配置：Type= (服务类型，如 simple, forking), ExecStart= (启动命令), WorkingDirectory=, User=, Group=, Restart=, RestartSec=, Environment=, EnvironmentFile=, 资源限制 (MemoryLimit=, CPUQuota=), 安全配置等。
    • [Install]: 定义如何启用（开机自启），如 WantedBy=multi-user.target。
  • 配置语法相对 Supervisor 的 INI 风格更结构化但也更复杂。
• 使用方式：
  • 命令行工具 systemctl：核心管理工具 (systemctl start|stop|restart|reload|status|enable|disable|is-active|is-enabled unit.service, systemctl daemon-reload, systemctl list-units, systemctl show 等)。
  • journalctl：查询和管理日志 (journalctl -u unit.service, journalctl -f, journalctl --since "1 hour ago" 等)。
  • systemd-analyze：分析系统启动性能。
• 优点：
  • 系统级集成： 作为 PID 1 深度集成到操作系统，管理整个系统生命周期和服务。
  • 强大的依赖管理： 确保服务启动顺序正确，处理复杂的依赖链。
  • 精细的资源控制： 通过 cgroups 提供业界标准的资源限制和隔离。
  • 统一日志系统： journald 提供强大、集中、结构化的日志记录和查询能力。
  • 丰富的功能集： 远超进程管理，涵盖挂载、定时任务、设备、用户会话等。
  • 高性能并行启动： 利用依赖关系和 socket 激活实现服务并行启动，加快系统启动速度。
  • 标准化： 现代 Linux 的事实标准，知识通用性强。
  • 安全性： 内置众多安全强化选项。
• 缺点：
  • 复杂性： 学习曲线陡峭，单元文件语法和概念较多。
  • “臃肿”争议： 批评者认为它职责过多，违反了 Unix 的“一个程序只做一件事”哲学。
  • 日志格式： journald 的二进制日志格式 (journalctl 可读) 需要适应，与传统文本日志工具集成有时需要额外配置（如转发到 syslog）。
  • 配置覆盖： 需要理解 /usr/lib/ 和 /etc/ 目录下单元文件的优先级和覆盖关系。
  • PID 1 责任： 作为 init，其稳定性和安全性至关重要，bug 影响范围更大。

第二部分：详细对比

第三部分：如何选择？

• 选择 Supervisor 当：
  • 你需要管理的是用户空间的应用进程（比如你的 Python Django app 的 Gunicorn workers, PHP-FPM 池, Node.js 应用, Redis, Celery workers 等）。
  • 你希望有一个简单、专注的进程监控和自动重启工具。
  • 你需要一个轻量级、易于配置的解决方案。
  • 你特别看重集中、易用的日志捕获和查看（尤其是 Web UI）。
  • 你在一个非特权用户环境下工作（例如，在共享主机或受限容器内）。
  • 你需要在容器内部管理多个进程（一个容器一个进程是理想，但有时需要多个，Supervisor 是常见选择）。
  • 你对系统启动、依赖链、资源限制、安全沙箱没有严格要求。
• 选择 Systemd 当：
  • 你需要管理的是系统级服务（如 sshd, nginx, postgresql, docker, cron 替代品）。
  • 你需要管理系统启动过程、挂载点、定时任务、设备等。
  • 服务之间有复杂的依赖关系需要精确控制启动顺序。
  • 你需要对服务进行精细化的资源限制（CPU, 内存, IO）。
  • 你需要利用强大的安全隔离特性加固服务。
  • 你希望利用统一的、结构化的日志系统 (journald) 及其强大的查询功能。
  • 你需要按需启动服务（Socket 激活）。
  • 你管理的是现代 Linux 服务器或桌面系统（Systemd 已是标准）。
  • 你需要管理用户会话内的服务。

第四部分：常见问题与注意事项

• 可以同时使用吗？可以，而且很常见！
  • 典型模式： 使用 Systemd 管理系统本身和核心基础设施服务 (Nginx, DB, Docker)，并确保 supervisord 服务本身随系统启动 (systemctl enable supervisord)。然后由 supervisord 来管理具体的应用进程 (App Server, Workers)。Systemd 负责确保 supervisord 存活，supervisord 负责确保应用进程存活。
• 避免混合管理同一进程： 绝对不要让 Systemd 和 Supervisor 同时尝试直接启动和管理同一个具体的应用进程（例如，既有一个 myapp.service 单元文件，又在 supervisord.conf 里配置了 [program:myapp]）。这会导致冲突、重复启动和不可预知的行为。管理边界要清晰。
• 容器内： 在 Docker 容器中，PID 1 的角色至关重要。如果容器需要运行多个进程，选择一个合适的 PID 1 进程管理器是必要的：
  • Supervisor: 是一个流行的选择，因为它简单轻量，适合管理少量应用进程。
  • Systemd: 也可以在特权容器内运行作为 PID 1，但这通常被认为比较重且复杂，除非容器需要模拟一个完整的系统环境。更轻量的方案 (如 Supervisor, S6, Tini + 自定义脚本) 更常见。
  • Tini: 一个极简的 init，主要解决僵尸进程回收和信号转发问题。如果只有一个主进程，使用 tini 作为 ENTRYPOINT 是推荐做法。如果需要管理多个进程，Tini 本身不够，需要搭配其他工具或脚本。
• 日志处理：
  • Supervisor: 确保配置好日志文件和轮转，避免磁盘占满。如果需要集成到中央日志系统，需要额外配置（如 Filebeat 读取 Supervisor 的日志文件或配置 Supervisor 输出到 syslog）。
  • Systemd: 优先使用 journalctl 查看日志。如果需要传统 syslog 文件，配置 journald 转发到 rsyslog/syslog-ng。

总结

• Supervisor 是一个优秀的、专注的进程监控工具。它擅长在用户空间确保单个或多个应用进程持续运行，提供简单的配置和友好的日志管理。它是管理应用层进程（尤其是在容器内或非特权环境下）的利器。
• Systemd 是一个全面的系统和服务管理框架。作为现代 Linux 的核心，它管理从系统启动到服务生命周期、资源、日志、安全等方方面面。它是管理系统级服务和基础设施组件的标准与强大工具。

选择哪一个取决于你要管理什么：

• 管理 你的应用代码的进程 (App Server, Worker) -> 优先考虑 Supervisor (通常由 Systemd 托管)。
• 管理 操作系统服务 (Web Server, DB, SSH, Cron, Mounts) -> 必须使用 Systemd。