深入解剖 systemd：从内核到用户空间的完整机制解析

让我们真正深入 systemd 的内部，从设计哲学、核心数据结构、启动流程、依赖解析算法、资源隔离机制到性能调优，进行一次彻底的机制剖析。

一、systemd 的设计哲学：为什么它长成这样？

要理解 systemd 的机制，首先要理解它要解决的根本问题：

传统 SysV init 的本质缺陷：

  • 串行启动，完全依赖 shell 脚本，无法并行
  • 无状态管理，启动后即失去对进程的控制权
  • 无法追踪派生进程（fork），导致停止服务时遗漏子进程
  • 依赖关系通过脚本内的手动顺序控制，脆弱且不可验证
  • 日志散落各处，难以统一查询

systemd 的设计目标：

  1. 确定性：启动顺序必须可预测、可验证
  2. 并行性：最大化利用多核 CPU 资源
  3. 可控性：全生命周期管理进程及其子孙进程
  4. 统一性：用一套机制管理所有系统资源
  5. 可观测性：集中式结构化日志

为实现这些目标，systemd 引入了几个关键的设计决策：

  • 以单元为原子操作对象，所有操作都是对单元的事务性操作
  • 依赖关系显式声明，而非隐含在脚本顺序中
  • 使用 cgroups 而非 PID 追踪进程，从根本上解决了”进程逃逸”问题
  • 采用事件驱动模型，而非轮询，使用 epoll 管理大量文件描述符

二、核心数据结构：单元（Unit）的完整剖析

systemd 的核心是 Unit 对象，它被实现为一个庞大的结构体（在源代码中为 struct Unit），包含了所有单元类型的公共字段。

2.1 单元的类型体系

Unit (抽象基类)
├── Service    (.service)  - 最核心，管理进程
├── Socket     (.socket)   - 监听套接字，触发按需启动
├── Target     (.target)   - 逻辑分组，纯同步点
├── Timer      (.timer)    - 时间触发器
├── Path       (.path)     - 文件路径触发器
├── Mount      (.mount)    - 挂载点管理
├── Automount  (.automount)- 自动挂载
├── Swap       (.swap)     - 交换分区
├── Device     (.device)   - 内核设备（udev 集成）
├── Scope      (.scope)    - 外部管理的进程组（如容器）
├── Slice      (.slice)    - 资源隔离层级（cgroup 树节点）
└── ...

2.2 单元的状态机

每个单元都有一个严格的状态机，这是 systemd 事务性的基础：

         inactive (未激活)
            │
            │  start 请求
            ▼
          activating (激活中)
            │
            │  ┌─────────┐
            │  │  reload         │
            │  ▼                 │
            ├──> active ────┤
            │  (运行中)           │
            │  ▲                 │
            │  └─────────┘
            │
            │  stop 请求
            ▼
         deactivating (停用中)
            │
            ▼
         inactive / failed

关键点：

  • 从 inactive 到 active 是”启动事务”（Job）
  • 每个状态转换都是一个原子事务，要么完全成功，要么完全回滚
  • failed 状态表示启动失败，需要手动 reset-failed 才能重新启动
  • reloading 是 active 的子状态，表示正在重载配置但不中断服务

2.3 单元文件解析机制

systemd 启动时会解析所有单元文件，构建一个全局单元图。解析过程如下：

  1. 查找路径优先级：
  • /etc/systemd/system —— 最高优先级，管理员自定义
  • /run/systemd/system —— 运行时临时配置
  • /lib/systemd/system —— 发行版提供的默认配置
  • /usr/lib/systemd/system —— 同上（部分发行版）
  1. 文件解析：
  • 使用 INI 格式，但支持更丰富的类型（bool、time、size、list）
  • 支持变量替换：%i 表示实例名，%n 表示单元名
  • 支持 Drop-in 目录：/etc/systemd/system/foo.service.d/*.conf，覆盖主配置
  1. 依赖关系提取：
  • 解析 [Unit] 部分的 Requires、Wants、Conflicts、After、Before
  • 解析 [Service] 部分的 ExecStartPre、ExecStart、ExecStartPost 等
  • 每个依赖都被记录为一个边（edge），加入依赖图

三、依赖关系与启动顺序：事务引擎详解

这是 systemd 最复杂也最精妙的部分。

3.1 依赖类型的语义区分

systemd 有四种主要依赖类型，它们的语义完全不同：

类型语义失败影响
Requires强依赖：本单元启动必须依赖目标单元成功启动目标失败 → 本单元也失败
Wants弱依赖：倾向启动目标单元，但不强制目标失败 → 不影响本单元
BindsTo绑定依赖：目标停止 → 本单元也必须停止目标停止 → 本单元强制停止
Conflicts冲突：本单元启动时，目标单元必须停止目标单元被自动停止

顺序关系（不是依赖，只是排序）：

  • After=xxx：本单元在 xxx 之后启动
  • Before=xxx：本单元在 xxx 之前启动

关键区别：

Requires=A + After=A  →  真正的依赖：A 启动成功后，本单元才启动
Requires=A 但不加 After  →  两者同时启动，但如果 A 失败，本单元也失败
Wants=A + After=A  →  尽量先启动 A，但 A 失败不影响本单元

3.2 循环依赖检测与打破

systemd 使用了拓扑排序算法来检测循环依赖：

算法：Tarjan 强连通分量（SCC）检测
1. 构建依赖图（有向图）
2. 对每个节点运行 DFS，标记访问状态
3. 如果发现反向边（back edge），则存在循环
4. 当循环被检测到，systemd 会：
   a. 检查循环中是否有单元设置了 `JobTimeout`
   b. 尝试通过 `Wants`（弱依赖）断开循环
   c. 如果无法打破，则报告 "Found ordering cycle" 错误并回滚

实际案例：

service-A Requires=service-B, After=service-B
service-B Requires=service-A, After=service-A
→ 检测到循环依赖，systemd 拒绝启动并报错

3.3 Job 调度引擎

当用户执行 systemctl start foo.service 时，systemd 内部经历了以下步骤：

1. 验证阶段（Verification）
   ├── 检查 foo.service 是否存在，单元文件是否有效
   ├── 解析其所有依赖（Requires、Wants、Conflicts）
   └── 构建一个 Job 列表（包含所有需要启动/停止的单元）

2. 排序阶段（Ordering）
   ├── 对 Job 列表进行拓扑排序（基于 After/Before 关系）
   ├── 检测循环依赖，若存在则报错并回滚
   └── 生成一个线性的启动序列

3. 执行阶段（Execution）
   ├── 按排序后的序列顺序执行 Job
   ├── 每个 Job 启动时，更新其状态（inactive → activating → active）
   ├── 如果某个 Job 失败，根据依赖类型决定：
   │   ├── Requires 依赖 → 整个事务回滚
   │   └── Wants 依赖 → 跳过，继续后续 Job
   └── 所有 Job 完成后，返回最终结果

注意：这里的”顺序执行”是指 Job 的启动顺序，但每个 Job 内部启动的服务本身的启动操作是并行的。例如，如果一个服务启动了多个子进程，这些子进程之间没有依赖关系，则它们会并行启动。

四、进程管理：Cgroups 的深度集成

这是 systemd 最核心的技术创新。

4.1 Cgroups v2 与 systemd 的层次结构

从 Linux 4.5+ 开始，cgroups v2 成为默认。systemd 是内核 cgroups 的管理器，它建立了一个层级结构：

/sys/fs/cgroup/
├── system.slice/          # 系统服务
│   ├── systemd-journald.service/
│   ├── sshd.service/
│   ├── nginx.service/
│   │   ├── cgroup.procs   # 包含所有 nginx 进程的 PID
│   │   └── memory.max     # 内存限制
│   └── ...
├── user.slice/            # 用户会话
│   ├── user-1000.slice/
│   │   ├── session-1.scope/
│   │   └── ...
├── machine.slice/         # 虚拟机/容器
│   └── ...
└── init.scope/            # init 自身 (PID 1)

4.2 进程的完整生命周期管理

启动过程：

1. systemd 接收到启动请求（如 systemctl start nginx）
2. 创建新的 cgroup：/sys/fs/cgroup/system.slice/nginx.service/
3. 使用 fork() 创建子进程
4. 在子进程中调用 setsid() 创建新会话
5. 写入 cgroup.procs，将 PID 加入 cgroup
6. 执行 ExecStart 指定的程序
7. 所有后续 fork 的子进程都会自动继承 cgroup（因为进程的 cgroup 是继承的）

停止过程：

1. systemd 收到停止请求
2. 从 cgroup.procs 读取所有 PID
3. 按顺序发送 SIGTERM（先给主进程，再给子进程）
4. 等待 KillMode 指定的时间（默认为 90 秒）
5. 如果进程未退出，发送 SIGKILL 强制终止
6. 删除 cgroup 目录

4.3 KillMode 的深度语义

这是 systemd 一个非常精细的控制点：

KillMode行为
control-group（默认）杀掉 cgroup 中所有进程（包括子进程），最彻底
process只杀掉主进程（cgroup 中的父进程），子进程会变成孤儿并被 init 收养
mixed主进程发 SIGTERM，子进程发 SIGKILL（用于清理遗留的 worker）
none不发送任何信号，只调用 stop 命令（如 ExecStop）

实际场景：

  • Nginx 有 master + worker 进程 → 使用 control-group 确保全部停止
  • Shell 脚本启动了后台子进程 → 使用 control-group 防止子进程成为僵尸
  • 数据库服务需要优雅关闭 → 使用 mixed，先让主进程处理完事务，再强制清理 worker

4.4 资源控制接口

通过 systemd，你可以对每个服务进行精细的资源限制：

[Service]
# CPU 限制：最多使用 2 个 CPU 核心的 50%
CPUQuota=50%
CPUWeight=100

# 内存限制：硬限制 1GB
MemoryMax=1G
MemoryHigh=800M  # 软限制，超过时开始压制

# IO 限制：权重为 1000（默认 100）
IOWeight=1000
IOReadBandwidthMax=/dev/sda 10M

# 进程数量限制
TasksMax=200

这些限制直接映射为 cgroups 的控制器参数，由内核强制执行，进程本身无法绕过。

五、Socket 激活：按需启动的深层机制

Socket 激活是 systemd 最巧妙的设计之一。

5.1 工作原理

传统模式：

用户请求 → 监听进程（已启动）→ 处理请求

Socket 激活模式：

用户请求 → systemd 监听的 socket → 启动服务进程 → systemd 传递 socket 文件描述符 → 服务处理请求

关键机制：

  1. systemd 在启动时创建并绑定 socket（如 :80），开始监听
  2. 但不启动对应的服务进程
  3. 当第一个连接到达时，systemd 触发 OnStartup 事件
  4. systemd 启动服务，并通过 $LISTEN_FDS 环境变量传递 socket fd
  5. 服务通过 sd_listen_fds() 接收 fd，直接开始处理
  6. 后续连接：服务已经在运行，直接处理，无需 systemd 介入

优势：

  • 启动加速：服务在真正需要时才启动
  • 零停机重启：重启服务时，systemd 继续持有 socket，新进程接管后无缝切换
  • 依赖最小化：多个服务可以共享同一个 socket，按需唤醒

5.2 传递机制的技术细节

systemd 使用 Unix 域套接字的 SCM_RIGHTS 机制传递文件描述符：

1. systemd 在启动时创建 socket，获得 fd 3
2. 当服务被启动时，systemd 调用 execve()
3. 在 exec 之前，systemd 保持 fd 3 不关闭（O_CLOEXEC 被清除）
4. 服务进程继承 fd 3，但不知道它的含义
5. 服务调用 sd_listen_fds() → 解析环境变量 LISTEN_FDS
6. 从 fd 3 开始往后数，获取所有传递的 fd

环境变量：

  • LISTEN_FDS=1：传递了 1 个文件描述符
  • LISTEN_FDNAMES=my-socket：传递给服务的 socket 名称
  • LISTEN_PID=1234：验证调用者的 PID，防止非法继承

六、日志系统 Journald：从设计到实现

6.1 日志数据结构

journald 使用二进制格式存储日志，每条日志包含：

struct JournalEntry {
    uint64_t    timestamp;        // 纳秒精度
    uint64_t    boot_id;          // 启动 ID，区分不同启动
    pid_t       pid;              // 进程 ID
    uid_t       uid;              // 用户 ID
    gid_t       gid;              // 组 ID
    char        *message;         // 日志消息
    char        *unit;            // 所属单元名
    int         priority;         // 优先级 (0-7)
    ... (更多字段)
    struct iovec *extra_fields;   // 额外字段（键值对）
}

关键特性：

  • 索引化：所有字段都被索引，支持快速查询
  • 压缩：使用 LZ4 或 XZ 压缩，节省存储空间
  • 顺序号：每条日志有一个单调递增的序列号，便于追踪
  • 签名：可选加密签名，保证日志不可篡改

6.2 日志的持久化与轮转

日志存储位置：

  • /run/log/journal/ → 运行时日志（内存，重启后丢失）
  • /var/log/journal/ → 持久化日志（磁盘）

轮转机制：

1. 当日志文件达到设定大小（默认 8GB）时，自动轮转
2. 保留最近 100 个日志文件
3. 系统空闲时自动压缩旧日志
4. 支持按时间、大小、数量三种策略轮转

6.3 Journal 与 Syslog 的桥接

systemd 同时支持传统 syslog：

  • journald 接收来自 /dev/log 的 syslog 消息
  • 可以通过 systemd-journal-remote 将日志转发到远程服务器
  • 可以使用 rsyslog 或 syslog-ng 从 journal 读取日志并转发

性能对比：

  • 传统 syslog：每条日志需要打开文件、写入、同步，约 10-20μs
  • journald：内存缓存 + 批处理写入，约 1-2μs（快 10 倍）

七、启动流程全链路分析

从内核到用户空间的完整路径：

1. 内核启动 → 加载 initramfs → 挂载根文件系统

2. 内核执行 /sbin/init（符号链接指向 /lib/systemd/systemd）
   └── systemd 作为 PID 1 启动

3. systemd 启动过程：
   ├── 阶段1：基础初始化
   │   ├── 挂载 /proc、/sys、/dev、/run
   │   ├── 启动 udev（设备管理）
   │   └── 初始化日志系统 journald
   │
   ├── 阶段2：执行 initrd（initramfs）中的单元
   │   ├── 加载必要的内核模块
   │   ├── 挂载早期文件系统
   │   └── 准备根文件系统切换
   │
   ├── 阶段3：切换根文件系统
   │   ├── 执行 /usr/lib/systemd/systemd 的重新执行（re-exec）
   │   ├── 从 initrd 的根切换到实际的根
   │   └── 重新加载所有单元文件
   │
   ├── 阶段4：启动系统服务（基于默认 target）
   │   ├── 默认 target 由 /etc/systemd/system/default.target 决定
   │   ├── 常见 target：
   │   │   ├── multi-user.target（多用户命令行）
   │   │   ├── graphical.target（图形界面）
   │   │   └── rescue.target（单用户救援模式）
   │   ├── 解析 target 的依赖树（Wants、Requires）
   │   ├── 按拓扑排序启动所有服务
   │   └── 关键服务并行启动（如 network.target 是所有网络服务的同步点）
   │
   └── 阶段5：进入系统就绪状态
       ├── 启动 getty 登录服务（或图形登录管理器）
       ├── 将系统状态设置为 "startup finished"
       └── systemd 进入事件循环，等待管理命令

7.1 关键 Target 的语义

Target语义包含内容
sysinit.target系统初始化完成挂载文件系统、启动 udev、初始化日志
basic.target基础系统就绪支持基本网络、D-Bus 就绪
network.target网络就绪所有网络接口已配置（但不一定通）
network-online.target网络完全可用网络已连通，可访问外部（延迟更大）
multi-user.target多用户命令行所有系统服务、终端登录
graphical.target图形界面multi-user.target + 图形服务

八、高级调优与故障排查

8.1 启动性能分析

# 总体启动耗时
systemd-analyze time

# 每个服务启动耗时（从大到小）
systemd-analyze blame

# 启动过程关键事件的时间线
systemd-analyze plot > boot.svg

# 查看某个特定服务的启动耗时
systemd-analyze show -p TimeUSStart nginx.service

8.2 状态检查与监控

# 查看系统整体状态
systemctl status

# 列出所有失败的单元
systemctl list-units --state=failed

# 监控服务状态变化（类似 tail -f）
systemctl status -f nginx.service

# 查看服务依赖树
systemctl list-dependencies nginx.service

# 显示所有套接字激活的服务
systemctl list-sockets

8.3 调试模式

# 启动时进入 debug shell（在 grub 启动参数中加入 systemd.debug-shell）
# 按 Ctrl+Alt+F9 进入 debug shell

# 开启 systemd 的调试日志
systemctl set-log-level debug

# 查看详细的启动过程
systemd-analyze verify /etc/systemd/system/foo.service

# 模拟启动但不实际执行（dry-run）
systemctl start --dry-run nginx.service

8.4 常见问题解决方案

问题1：服务启动超时

# 修改默认超时时间（默认 90 秒）
[Service]
TimeoutStartSec=300
TimeoutStopSec=300

问题2：服务启动后立即退出，状态为 inactive

# 查看详细日志
journalctl -u nginx.service -f

# 可能是 Type 设置错误：
# - 如果进程 fork 后退出，用 Type=forking
# - 如果进程持续前台运行，用 Type=simple
# - 如果是 DBus 服务，用 Type=dbus

问题3：大量文件描述符泄漏

# 查看某个进程的 fd 数量
lsof -p PID | wc -l

# 通过 cgroup 限制 fd 数量
[Service]
LimitNOFILE=65536

九、systemd 的批评与局限性

客观地说，systemd 并非完美：

  1. 违背 Unix 哲学：一个程序做太多事（init、logind、journald、timedated、hostnamed…），增加攻击面
  2. 与内核强耦合：依赖 cgroups v2，旧内核不支持（RHEL 7 仍用 cgroup v1）
  3. 学习曲线陡峭：配置文件语法复杂，单元类型众多，新手容易出错
  4. 调试困难：一旦 systemd 自身出问题（如 PID 1 卡死），整个系统瘫痪，无法介入
  5. 二进制日志：journald 的二进制格式对人类不友好，journalctl 虽然强大但增加了复杂度
  6. 生态垄断：许多 Linux 组件（如 GNOME、KDE）开始直接依赖 systemd，导致其他 init 系统难以使用

十、总结

systemd 是现代 Linux 系统的基础设施层，它不仅仅是”一个 init 程序”，而是一个完整的系统管理层：

  • 进程管理：通过 cgroups 精细控制每个服务的生命周期和资源
  • 依赖管理：通过事务引擎可靠地处理启动顺序和依赖关系
  • 按需启动：通过 socket/dbus/path/timer 多种触发机制节约资源
  • 日志管理：通过 journald 提供集中化、结构化、高性能的日志系统
  • 资源控制：通过 cgroups v2 实现 CPU、内存、IO 的精细化隔离

理解 systemd 的机制，本质上是在理解现代 Linux 系统的运行逻辑。它可能不完美，但无疑是 Linux 生态系统中最重要、最核心的组件之一。掌握它，你就掌握了系统管理的主动权。

作者

老丹

关注我
其他文章