2.12 systemd 深入——Unit 编写与高级特性

预计阅读时间：9 分钟

学习目标

• 掌握 systemd Unit 文件三段式结构（[Unit] / [Service] / [Install]）
• 区分 5 种 Type= 及其适用场景
• 用 Socket Activation 实现按需启动服务
• 用 systemd timer 替代 cron 管理定时任务
• 配置 journald 持久化存储与日志限额
• 用 systemd-analyze 诊断与优化系统启动时间

核心知识

知识关联

• 前置知识：2.7：日志与故障排查 日志与故障排查（journalctl 基础用法）
• 后续影响：3.15：Cron 定时任务 Cron 高级定时任务（systemd timer 是 cron 的现代替代），4.8：集中式日志管理 集中式日志管理（journald 远程转发）
• 配套技术：systemd timer 优势在随机延迟、持久化、资源控制与统一日志；journald 提供比 /var/log/syslog 更强大的结构化过滤。

原理讲解

systemd 作为 PID 1，采用并行化与按需启动两大设计原则替代传统 SysV init。其核心抽象是 Unit——每个 Unit 是一个配置文件，描述一个系统资源及其管理方式。

依赖关系维度：

• 顺序（Order）：After= / Before= —— 只控制启动顺序，不强制需求。写 After=postgresql.service 单独使用，postgresql 启动失败你的服务仍然会启动。
• 需求（Requirement）：Requires=（硬） / Wants=（软） / BindsTo=（强绑定）—— 对方状态影响本服务。
• 最佳组合：After= + Requires= 或 After= + Wants= 同时声明顺序与依赖。

Target 依赖链——从开机到服务的完整路径

Target 是 systemd 的"分组单元"，对应传统 SysV 的运行级别（runlevel），但功能更强：Target 之间也有 Wants= / Requires= / After= 依赖，形成一个从硬件初始化到用户登录的有向无环图。

# 查看 multi-user.target 依赖了谁（及其顺序）
systemctl list-dependencies multi-user.target
# 输出（节选）:
# multi-user.target
# ├─dbus.service
# ├─network.target
# ├─sshd.service
# ├─cron.service
# └─systemd-logind.service

# 切换运行级别（传统 init 3/5 的现代等价物）
systemctl isolate multi-user.target    # 进入命令行模式
systemctl isolate graphical.target    # 回到图形界面

# 查看默认启动目标
systemctl get-default
# 输出: graphical.target

systemd.exec 安全字段——让服务"跑在笼子里"

systemd 自带一套类似容器的沙箱能力（不需要 Docker 就能限制服务）。生产环境的 [Service] 段建议按需启用：

# 查看某个服务实际生效的安全限制
systemd-analyze security sshd.service
# 输出（节选）:
# → Overall exposure level for sshd.service: 5.4 EXPOSED
# → PrivateTmp=yes                                0.1
# → PrivateDevices=yes                            0.1
# → ProtectSystem=full                            0.5
# → NoNewPrivileges=yes                           0.2

示例代码

基础 Service Unit

[Unit]
Description=My Custom Application
Documentation=https://docs.example.com
After=network-online.target postgresql.service
Requires=postgresql.service
Wants=redis.service

[Service]
Type=simple
User=appuser
Group=appuser
WorkingDirectory=/opt/myapp
EnvironmentFile=-/etc/myapp/env.conf
ExecStart=/usr/bin/java -jar /opt/myapp/app.jar
ExecStartPre=/usr/local/bin/check-config.sh
ExecStop=/usr/local/bin/graceful-shutdown.sh
ExecReload=/usr/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5
TimeoutStartSec=60
TimeoutStopSec=30
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

三种 Service Type 对比

# simple — 前台进程，ExecStart 启动即就绪
[Service]
Type=simple
ExecStart=/usr/local/bin/uvicorn main:app

# forking — 先父后子，需要 PIDFile
[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -q
ExecStart=/usr/sbin/nginx

# oneshot — 执行一次即退出，常与 RemainAfterExit=yes 配合
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/init-cluster.sh
ExecStop=/usr/local/bin/cleanup-cluster.sh

# 验证 & 测试
systemd-analyze verify /etc/systemd/system/myapp.service
systemctl daemon-reload
systemctl start myapp.service
systemctl status myapp.service
# 输出: ● myapp.service - My Custom Application
#          Loaded: loaded (/etc/systemd/system/myapp.service; disabled)
#          Active: active (running) since ...

Timer Unit — 替代 Cron

# /etc/systemd/system/db-backup.service
[Unit]
Description=Database backup
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-db.sh
User=backup

# /etc/systemd/system/db-backup.timer
[Unit]
Description=Daily backup at 02:30
[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=300
Persistent=true
[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now db-backup.timer
systemctl list-timers --all
# 输出: NEXT                        LEFT       LAST  PASSED  UNIT
#       Fri 2026-07-31 02:30:00  4h 23min  n/a   n/a    db-backup.timer

journald 配置

# /etc/systemd/journald.conf
[Journal]
Storage=persistent
SystemMaxUse=500M
SystemMaxFileSize=100M
MaxRetentionSec=2week
ForwardToSyslog=no
Compress=yes

mkdir -p /var/log/journal && systemctl restart systemd-journald
journalctl --vacuum-size=300M
journalctl -u nginx.service -S "1 hour ago" -p err --no-pager
# 输出（示例）:
# Jul 30 10:15:01 host nginx[1234]: 2026/07/30 10:15:01 [error] ...

Socket Activation

# /etc/systemd/system/myapp.socket
[Unit]
Description=My App Activation Socket
[Socket]
ListenStream=0.0.0.0:8080
Accept=no
SocketUser=appuser
SocketMode=0660
[Install]
WantedBy=sockets.target

# /etc/systemd/system/myapp.service 无需 enable
[Service]
Type=simple
User=appuser
ExecStart=/usr/bin/myapp  # 应用从 sd_listen_fds(3) 取 socket

systemctl enable --now myapp.socket
systemctl list-sockets
# 输出: LISTEN        UNIT         ACTIVATES
#       0.0.0.0:8080  myapp.socket myapp.service

生产级安全加固 Service 模板

# /etc/systemd/system/backend.service
[Unit]
Description=Backend API Server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=backend
Group=backend
WorkingDirectory=/opt/backend
ExecStart=/usr/bin/python3 /opt/backend/server.py
Restart=on-failure
RestartSec=3

# 资源限制
LimitNOFILE=65536
LimitNPROC=4096
MemoryMax=2G
MemoryHigh=1.5G
CPUQuota=150%
TasksMax=256

# 安全沙箱
PrivateTmp=yes
PrivateDevices=yes
ProtectSystem=strict
ProtectHome=read-only
ProtectKernelTunables=yes
ProtectKernelModules=yes
NoNewPrivileges=yes
ReadWritePaths=/var/lib/backend /var/log/backend
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX

# 环境
Environment=NODE_ENV=production
EnvironmentFile=-/etc/backend/env.conf

[Install]
WantedBy=multi-user.target

# 验证：用 systemd-analyze 检查配置合法性，再看安全评分
systemd-analyze verify /etc/systemd/system/backend.service
systemd-analyze security backend.service
# 输出: → Overall exposure level for backend.service: 1.4 OK

Path 单元——文件变化触发任务

# /etc/systemd/system/upload-watch.path
[Unit]
Description=Watch upload directory
[Path]
PathExistsGlob=/srv/uploads/*
DirectoryNotEmpty=/srv/uploads
[Install]
WantedBy=multi-user.target

# /etc/systemd/system/upload-watch.service
[Unit]
Description=Process new uploads
[Service]
Type=oneshot
ExecStart=/usr/local/bin/process-uploads.sh
User=appuser

systemctl enable --now upload-watch.path
# 任何文件落入 /srv/uploads 目录时自动触发 process-uploads.sh
systemctl list-units --type=path
# 输出: upload-watch.path  loaded active watching  Watch upload directory

常见错误

最佳实践

练习题

1. 概念题：After= 和 Requires= 有什么区别？写出一个同时使用二者的典型配置段。
2. 概念题：systemd timer 相比 cron 的四个主要优势是什么？
3. 实操题：为一个 Flask/Gunicorn Web 应用（启动命令 /usr/local/bin/gunicorn -w 4 app:app）编写生产级 .service 文件，要求：Type=simple、User=webapp、自动重启、限制文件描述符 65536、启用 PrivateTmp。验证后用 systemctl enable 设置开机启动。
4. 实操题：配合上题 Web 服务，创建一个 web-healthcheck.timer，每小时执行 /usr/local/bin/healthcheck.sh，要求随机延迟 60 秒、错过时间后补执行。验证 list-timers 输出。
5. 🔍 挑战题：你的服务器启动时间从 15s 恶化到 45s。请列出使用 systemd-analyze 诊断的完整步骤，并说明每种可能的根因和对应的修复方法。提示：考虑 NetworkManager-wait-online.service、磁盘挂载超时、废弃服务残留等。

本章总结

速查表

学习路径建议：

1. 用 systemctl cat 查看系统中已有的 unit 文件，逐行理解每个指令
2. 仿照本章示例，创建一个你自己的 /etc/systemd/system/test-app.service
3. 将系统上现有的 cron 任务逐个迁移到 systemd timer，体会二者的差异
4. 在测试机上运行 systemd-analyze blame 并针对 top 3 做启动优化
5. 阅读 man systemd.service / man systemd.timer / man journald.conf

延伸阅读