Linux进程管理深入对比：从SysVinit到systemd 256的Unit文件配置与快速启动实践

本文基于2026年最新的 systemd 256 版本，为你深入剖析现代 Linux 进程管理机制与传统 SysVinit 系统的核心差异。无论你是想优化服务器启动速度，还是需要精细化管理微服务依赖，理解这两者的工作原理都是现代运维工程师的必备技能。

一、概述

1.1 背景介绍

Linux 系统的进程管理走过了一条漫长的演进之路：从经典的 SysVinit，到尝试改进的 Upstart，再到如今已成主流的 systemd。SysVinit 作为 Unix System V 的遗产，自 1983 年起为 Linux 社区服务了近 30 年。然而，其串行启动机制和依赖 Shell 脚本的管理方式，在现代多核服务器和复杂服务依赖的环境下，逐渐显得力不从心。

2010 年，Lennart Poettering 和 Kay Sievers 发起了 systemd 项目，旨在从根本上解决传统 init 系统的缺陷。经过十多年的发展，systemd 已成为 RHEL、Debian、Ubuntu、Arch Linux 等主流发行版的标准 init 系统。截至 2026 年，systemd 256 版本引入了更强大的资源控制能力、改进的容器支持以及增强的安全特性。

对于运维工程师而言，理解 systemd 与传统 init 系统的差异至关重要。无论是进行系统启动优化、管理服务依赖关系，还是进行故障排查与性能调优，都离不开对这些核心机制的理解。

1.2 技术特点对比

特性维度	SysVinit	systemd
启动方式	串行执行，按运行级别顺序启动	并行启动，基于依赖关系动态调度
配置格式	Shell脚本（/etc/init.d/）	声明式Unit文件（INI格式）
依赖管理	数字前缀隐式排序	显式声明 After/Before/Requires/Wants
进程追踪	PID文件，易丢失	cgroups精确追踪所有子进程
日志系统	分散的文本日志	journald二进制结构化日志
资源控制	无原生支持	完整 cgroups v2 集成
Socket激活	需借助 xinetd	原生支持按需启动
启动速度	通常60-120秒	通常10-30秒

systemd 的核心优势包括：

• 并行化启动：通过解析服务间的依赖关系图，实现最大化并行，显著缩短系统启动时间。
• 按需激活：支持 Socket、D-Bus、Path、Timer 等多种激活机制，服务只在真正需要时才启动，资源利用更高效。
• 统一管理接口：systemctl 命令提供了对服务、挂载点、设备、定时器等单元的一致性操作体验。
• 精确进程控制：基于 Linux 内核的 cgroups 实现进程隔离与资源限制，管理粒度更细。
• 事务性操作：服务的启动、停止操作具备原子性，失败时能自动回滚，提升了系统状态的一致性。
• 丰富的安全特性：原生支持命名空间隔离、能力(Capabilities)限制、系统调用过滤等安全加固手段。

1.3 适用场景分析

何时应选择 systemd？

• 云原生服务器：需要快速启动、弹性伸缩的云主机或虚拟机环境。
• 容器宿主机：与 Docker、Podman 等容器运行时深度集成，便于管理容器化服务。
• 微服务架构：服务数量多，依赖关系复杂，需要强大的依赖管理与健康检查功能。
• 高可用集群：依赖服务的自动重启、故障隔离与自愈能力。
• 安全敏感环境：需要对进程进行严格的隔离与权限最小化控制。

SysVinit 仍有其价值：

• 嵌入式系统：资源高度受限的设备，systemd 的内存和性能开销可能过大。
• 遗留系统维护：维护老旧发行版时，出于兼容性考虑。
• 极简主义环境：追求系统极致简洁与可控性的特殊用途服务器或运维环境。
• 调试与学习：为了深入理解 Unix 进程管理的基础原理。

1.4 环境要求

组件	版本要求	说明
Linux内核	4.15+（推荐5.15 LTS或6.x）	cgroups v2 需要 4.15+，完整特性需 5.x+
systemd	250+（当前稳定版256）	本文示例基于 256 版本
glibc	2.28+	systemd 编译依赖
发行版	RHEL 8+/Debian 11+/Ubuntu 20.04+	主流发行版默认集成
内存	最低512MB，推荐2GB+	systemd 本身占用约 50-100MB
存储	/var/log 预留2GB+	用于存储 journald 日志

---

二、详细步骤与核心概念对比

2.1 准备工作

2.1.1 系统环境检查

首先，确认你当前系统的 init 系统类型和版本。

# 检查init系统类型
ps -p 1 -o comm=
# 输出 systemd 表示使用systemd，输出 init 可能是SysVinit

# 查看systemd版本
systemctl --version
# systemd 256 (256.2-1)
# +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT...

# 检查cgroups版本
cat /sys/fs/cgroup/cgroup.controllers
# cpuset cpu io memory hugetlb pids rdma misc
# 有输出表示cgroups v2已启用

# 确认内核版本
uname -r
# 6.5.0-44-generic

2.1.2 SysVinit环境准备（用于对比测试）

如果你想在同一个环境中对比测试，可以通过容器来模拟传统的 SysVinit 系统。

# 使用Docker运行SysVinit环境（Devuan发行版保留SysVinit）
docker run -d --name sysvinit-test \
    --privileged \
    -v /sys/fs/cgroup:/sys/fs/cgroup:ro \
    dyne/devuan:chimaera /sbin/init

# 进入容器验证
docker exec -it sysvinit-test /bin/bash
ps -p 1 -o comm=
# init

2.1.3 工具安装

安装一些用于分析和管理的工具。

# RHEL/CentOS系统
sudo dnf install -y systemd-analyze systemd-container procps-ng

# Debian/Ubuntu系统
sudo apt install -y systemd-analyze systemd-container procps

# 安装性能分析工具
sudo apt install -y bootchart2 python3-systemd

2.2 核心概念对比

2.2.1 运行级别 (Runlevel) vs 目标单元 (Target)

这是两者最直观的区别之一。

SysVinit 运行级别：
用数字 0-6 表示系统状态，启动是串行地按数字顺序执行对应目录下的脚本。

# 查看当前运行级别
runlevel
# N 3

# 运行级别定义
# 0 - 关机
# 1 - 单用户模式（维护）
# 2 - 多用户模式（无网络，Debian特有）
# 3 - 多用户模式（命令行）
# 4 - 未定义（用户自定义）
# 5 - 图形界面模式
# 6 - 重启

# 切换运行级别
sudo init 3
sudo telinit 5

systemd 目标单元：
用“target”这个概念替代了运行级别，它更像一个逻辑组，可以灵活地定义系统状态。

# 查看当前默认target
systemctl get-default
# multi-user.target

# 列出所有target
systemctl list-units --type=target

# target与运行级别的大致对应关系
# runlevel0.target -> poweroff.target
# runlevel1.target -> rescue.target
# runlevel2.target -> multi-user.target
# runlevel3.target -> multi-user.target
# runlevel4.target -> multi-user.target
# runlevel5.target -> graphical.target
# runlevel6.target -> reboot.target

# 切换到某个target
sudo systemctl isolate multi-user.target
sudo systemctl isolate graphical.target

# 设置默认target
sudo systemctl set-default multi-user.target

systemd 的优势在于可以清晰查看 target 内部的依赖关系。

# 查看target依赖树
systemctl list-dependencies graphical.target

# 输出示例：
# graphical.target
# ├─display-manager.service
# ├─multi-user.target
# │ ├─dbus.service
# │ ├─NetworkManager.service
# │ ├─sshd.service
# │ └─...
# └─...

2.2.2 启动脚本 vs Unit 文件

这是配置管理方式的根本不同。

SysVinit 启动脚本结构：
本质是一个支持 start, stop, status 等参数的 Shell 脚本。

#!/bin/bash
# /etc/init.d/myservice
# chkconfig: 2345 90 10
# description: My Custom Service

### BEGIN INIT INFO
# Provides:          myservice
# Required-Start:    $network $syslog
# Required-Stop:     $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: My Service
# Description:       This is my custom service
### END INIT INFO

DAEMON=/usr/local/bin/myservice
PIDFILE=/var/run/myservice.pid
NAME=myservice

case "$1" in
    start)
        echo "Starting $NAME..."
        if [ -f $PIDFILE ]; then
            echo "$NAME is already running."
            exit 1
        fi
        $DAEMON &
        echo $! > $PIDFILE
        ;;
    stop)
        echo "Stopping $NAME..."
        if [ -f $PIDFILE ]; then
            kill $(cat $PIDFILE)
            rm -f $PIDFILE
        else
            echo "$NAME is not running."
        fi
        ;;
    restart)
        $0 stop
        sleep 2
        $0 start
        ;;
    status)
        if [ -f $PIDFILE ] && kill -0 $(cat $PIDFILE) 2>/dev/null; then
            echo "$NAME is running (PID: $(cat $PIDFILE))"
        else
            echo "$NAME is not running"
            exit 1
        fi
        ;;
    *)
        echo "Usage: $0 {start|stop|restart|status}"
        exit 1
        ;;
esac
exit 0

systemd Unit 文件结构：
采用声明式的 INI 格式配置文件，你只需要告诉 systemd “做什么”，而不是“怎么做”。

# /etc/systemd/system/myservice.service
[Unit]
Description=My Custom Service
Documentation=https://example.com/docs
After=network.target syslog.target
Wants=network-online.target
Before=multi-user.target

[Service]
Type=simple
ExecStart=/usr/local/bin/myservice
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/bin/kill -TERM $MAINPID
Restart=on-failure
RestartSec=5
TimeoutStartSec=30
TimeoutStopSec=30

# 安全加固
User=myservice
Group=myservice
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes

[Install]
WantedBy=multi-user.target

两者对比分析：

维度	SysVinit脚本	systemd Unit
代码量	50-200行Shell	20-50行声明式配置
可读性	需理解Shell逻辑	直观的键值对
错误处理	手动编写	框架自动处理
依赖声明	LSB注释块	显式 After/Requires
进程追踪	PID文件	cgroups自动追踪
重启策略	手动实现	Restart= 配置

2.2.3 进程追踪机制对比

如何知道一个服务是否在运行？两者的做法天差地别。

SysVinit 的 PID 文件困境：
传统方式依赖 PID 文件，但这种方式问题很多。

# 传统PID文件管理存在的问题
cat /var/run/nginx.pid
# 1234

# 问题1：PID重用导致误判
# 进程1234已死亡，但PID被新进程复用
ps -p 1234 -o comm=
# python3  （不是nginx！）

# 问题2：fork后PID文件未更新
# 守护进程double-fork后，PID文件记录的是中间进程

# 问题3：异常退出PID文件残留
ls -la /var/run/*.pid
# 存在大量僵尸PID文件

systemd 的 cgroups 追踪：
利用 Linux 内核的 control groups (cgroups) 机制，精确追踪服务及其所有子进程。

# 查看服务的cgroup层级
systemctl status nginx.service
# CGroup: /system.slice/nginx.service
#         ├─1234 nginx: master process
#         ├─1235 nginx: worker process
#         └─1236 nginx: worker process

# 精确列出服务所有进程
systemd-cgls -u nginx.service

# 查看cgroup资源使用
systemctl show nginx.service -p MemoryCurrent -p CPUUsageNSec
# MemoryCurrent=52428800
# CPUUsageNSec=1234567890

# cgroups v2路径
ls /sys/fs/cgroup/system.slice/nginx.service/
# cgroup.controllers  cgroup.events  memory.current  pids.current

2.3 启动流程深度对比

2.3.1 SysVinit 串行启动流程

启动就像排队，一个接一个。

# SysVinit启动顺序（/etc/rc3.d/目录）
ls -la /etc/rc3.d/
# S01networking
# S02dbus
# S03rsyslog
# S10ssh
# S20nginx
# S90myapp

# 启动顺序由S后的数字决定，严格串行执行
# 总启动时间 = Σ(每个服务启动时间)

假设每个服务启动时间固定，串行启动的总耗时就是简单相加。

2.3.2 systemd 并行启动流程

systemd 会分析 Unit 文件中的依赖关系（After, Requires 等），绘制出一张依赖关系图。没有依赖关系的服务可以同时启动。

# 分析systemd启动时间
systemd-analyze
# Startup finished in 2.5s (kernel) + 4.8s (initrd) + 12.3s (userspace) = 19.6s

# 查看各服务启动耗时详情（从慢到快）
systemd-analyze blame
# 5.234s NetworkManager-wait-online.service
# 2.123s docker.service
# 1.456s nginx.service
# 0.892s ssh.service
# ...

# 生成启动时序SVG图（可用于可视化分析）
systemd-analyze plot > /tmp/boot-timeline.svg

你还可以找出启动过程中的“关键路径”，即那条最长的、决定整体启动时间的依赖链。

# 查看启动关键路径
systemd-analyze critical-chain
# graphical.target @12.3s
# └─multi-user.target @12.3s
#   └─nginx.service @10.8s +1.5s
#     └─network-online.target @10.7s
#       └─NetworkManager-wait-online.service @5.4s +5.3s
#         └─NetworkManager.service @5.2s +0.2s
#           └─dbus.service @5.0s +0.1s

2.3.3 依赖关系管理

systemd 提供了丰富而清晰的依赖关系声明方式，这是实现并行化和可靠性的基础。

依赖类型	作用	示例
Requires=	强依赖，依赖失败则本服务失败	Requires=postgresql.service
Wants=	弱依赖，依赖失败不影响本服务	Wants=redis.service
After=	启动顺序，在指定服务后启动	After=network.target
Before=	启动顺序，在指定服务前启动	Before=multi-user.target
BindsTo=	绑定依赖，依赖停止则本服务也停止	BindsTo=docker.service
PartOf=	部分依赖，随依赖一起重启/停止	PartOf=nginx.service
Conflicts=	冲突关系，不能同时运行	Conflicts=sendmail.service

你可以方便地查看这些关系：

# 查看服务依赖了哪些其他单元
systemctl list-dependencies nginx.service

# 反向查看哪些单元依赖了本服务
systemctl list-dependencies --reverse nginx.service

# 验证Unit文件语法和依赖关系（预防循环依赖等错误）
systemd-analyze verify /etc/systemd/system/myservice.service

---

三、示例代码和配置

3.1 完整配置示例

3.1.1 生产级 Web 服务 Unit 文件

这是一个综合了依赖管理、资源限制和安全配置的示例。

# /etc/systemd/system/webapp.service
[Unit]
Description=Production Web Application Server
Documentation=https://docs.example.com/webapp
After=network-online.target postgresql.service redis.service
Wants=network-online.target
Requires=postgresql.service
BindsTo=redis.service

# 条件检查
ConditionPathExists=/opt/webapp/bin/server
ConditionPathIsDirectory=/opt/webapp/data

[Service]
Type=notify
User=webapp
Group=webapp
WorkingDirectory=/opt/webapp

# 环境配置
Environment=NODE_ENV=production
Environment=PORT=8080
EnvironmentFile=-/opt/webapp/.env

# 启动命令
ExecStartPre=/opt/webapp/bin/pre-start.sh
ExecStart=/opt/webapp/bin/server --config /opt/webapp/config.yaml
ExecStartPost=/opt/webapp/bin/post-start.sh
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/opt/webapp/bin/graceful-stop.sh

# 重启策略
Restart=on-failure
RestartSec=10
StartLimitIntervalSec=300
StartLimitBurst=5

# 超时设置
TimeoutStartSec=60
TimeoutStopSec=30
WatchdogSec=30

# 资源限制 (cgroups v2)
MemoryMax=2G
MemoryHigh=1.5G
CPUQuota=200%
TasksMax=512
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

3.1.2 安全加固配置模板

对于安全要求高的服务，systemd 提供了大量沙箱选项。

# /etc/systemd/system/secure-app.service
[Unit]
Description=Security Hardened Application
After=network.target

[Service]
Type=simple
ExecStart=/opt/secure-app/bin/app
User=secapp
Group=secapp

# 文件系统保护
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ReadWritePaths=/var/lib/secure-app
ReadOnlyPaths=/etc/secure-app

# 网络隔离
PrivateNetwork=no
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX

# 权限限制
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE

# 系统调用过滤
SystemCallFilter=@system-service
SystemCallArchitectures=native

# 命名空间隔离
PrivateDevices=yes
PrivateUsers=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes

[Install]
WantedBy=multi-user.target

3.1.3 Socket 激活配置

这是 systemd 的一大特色，服务只在有连接请求时才启动。

# /etc/systemd/system/myapp.socket
[Unit]
Description=MyApp Socket Activation

[Socket]
ListenStream=8080
Accept=no
ReusePort=yes

[Install]
WantedBy=sockets.target

# /etc/systemd/system/myapp.service
[Unit]
Description=MyApp Service
Requires=myapp.socket

[Service]
Type=simple
ExecStart=/opt/myapp/bin/server
StandardInput=socket

[Install]
WantedBy=multi-user.target

配置好后，启用 myapp.socket 即可。当有连接到达 8080 端口时，myapp.service 才会被启动。

3.2 实际应用案例

案例一：微服务架构服务管理

场景：一个电商平台包含订单、库存、支付等多个服务，需要统一管理启动顺序。
方案：创建一个 Target 单元来聚合这些服务。

# /etc/systemd/system/ecommerce.target
[Unit]
Description=E-Commerce Platform Services
Requires=order.service inventory.service payment.service
After=network-online.target postgresql.service

[Install]
WantedBy=multi-user.target

# 一键启动整个电商平台
sudo systemctl start ecommerce.target
# 查看整体状态
sudo systemctl status ecommerce.target

案例二：定时任务从 cron 迁移到 systemd Timer

场景：将传统的 crontab 备份任务迁移，以获得更好的日志、依赖管理和随机延迟。
原 cron 配置：

# /etc/crontab
0 2 * * * root /opt/backup/daily-backup.sh

systemd Timer 实现：

# /etc/systemd/system/daily-backup.timer
[Unit]
Description=Daily Backup Timer

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=300

[Install]
WantedBy=timers.target

# /etc/systemd/system/daily-backup.service
[Unit]
Description=Daily Backup Service
After=network-online.target

[Service]
Type=oneshot
ExecStart=/opt/backup/daily-backup.sh
User=backup
Group=backup

# 启用并立即激活定时器
sudo systemctl enable --now daily-backup.timer
# 查看所有定时器状态
systemctl list-timers --all

---

四、最佳实践和注意事项

4.1 最佳实践

4.1.1 性能优化

启动时间优化：

# 1. 识别瓶颈
systemd-analyze blame | head -20

# 2. 禁用非必要服务（谨慎操作）
sudo systemctl disable NetworkManager-wait-online.service
sudo systemctl mask plymouth-quit-wait.service

# 3. 善用Socket激活延迟启动
sudo systemctl enable myapp.socket
sudo systemctl disable myapp.service

资源限制配置（在 [Service] 段）：

MemoryMax=2G
MemoryHigh=1.5G
CPUQuota=150%
CPUWeight=100
IOWeight=100
IOReadBandwidthMax=/dev/sda 100M

4.1.2 安全加固

systemd 内置了安全分析工具。

# 分析服务安全评分
systemd-analyze security nginx.service
# nginx.service: 6.5 MEDIUM

# 查看详细安全建议
systemd-analyze security nginx.service --no-pager

基础安全加固清单：

配置项	作用	推荐值
NoNewPrivileges	禁止进程获得新特权	yes
ProtectSystem	保护 /usr, /boot, /etc 等系统目录	strict
ProtectHome	保护用户家目录	yes
PrivateTmp	使用独立的临时目录	yes
PrivateDevices	限制对物理设备的访问	yes

4.1.3 高可用配置

配置服务在失败时自动恢复。

Restart=on-failure
RestartSec=10
StartLimitIntervalSec=300
StartLimitBurst=5
WatchdogSec=30

4.2 注意事项

4.2.1 配置注意事项

⚠️ 警告：修改任何 Unit 文件后，必须执行 daemon-reload 让 systemd 重新读取配置。

• sudo systemctl daemon-reload
• 避免直接编辑 /usr/lib/systemd/system/ 下的文件，应覆盖在 /etc/systemd/system/ 下。
• 使用 drop-in 目录进行灵活配置：/etc/systemd/system/<service名>.service.d/override.conf

4.2.2 常见错误

错误现象	原因分析	解决方案
服务启动超时	ExecStart 命令阻塞或 Type 配置错误（如应为 forking 却设为 simple）	检查服务类型，对于传统守护进程使用 Type=forking 或让服务支持 Type=notify
依赖循环	After/Requires 指令形成了闭环	使用 systemd-analyze verify <unit文件> 检查依赖
权限拒绝	SELinux 策略、文件系统权限或 Capabilities 不足	查看 journalctl -xe 和 audit 日志，调整策略或权限

---

五、故障排查和监控

5.1 故障排查

5.1.1 日志查看

告别到处找 log 文件的日子，journalctl 是首选工具。

# 实时追踪某个服务的日志
sudo journalctl -u nginx.service -f

# 查看本次启动以来该服务的所有日志
sudo journalctl -u nginx.service -b --no-pager

# 按精确时间范围查询
sudo journalctl -u nginx.service --since "2026-01-01 00:00:00" --until "2026-01-01 12:00:00"

5.1.2 常见问题排查

问题：服务启动失败

# 第一步：看状态
systemctl status nginx.service
# 第二步：看详细日志（-xe 显示最近错误及相关日志）
journalctl -xe -u nginx.service

解决思路：检查 ExecStart 命令路径、配置文件语法、运行用户权限及依赖服务状态。

问题：服务频繁重启

# 查看重启次数
systemctl show nginx.service -p NRestarts

解决思路：调整 [Service] 段中的 StartLimitIntervalSec、StartLimitBurst 和 RestartSec 参数。

5.2 性能监控

5.2.1 关键指标监控

# 查看服务当前资源使用情况
systemctl show nginx.service -p MemoryCurrent -p CPUUsageNSec

# 直接读取cgroup接口的原始数据（更底层）
cat /sys/fs/cgroup/system.slice/nginx.service/memory.current

5.2.2 监控指标说明

指标名称	正常范围	告警阈值	说明
MemoryCurrent	<80% 限制值	>90% 限制值	当前内存使用量
CPUUsageNSec	视业务而定	持续高位	CPU 累计使用时间（纳秒）
NRestarts	0	>3 次/小时	服务重启次数

---

六、总结

6.1 技术要点回顾

• 架构差异：systemd 的并行启动和依赖图模型，彻底改变了 SysVinit 串行脚本的执行方式。
• 配置方式：声明式的 Unit 文件 (INI格式) 比命令式的 Shell 脚本更简洁、清晰，将“做什么”与“怎么做”解耦。
• 进程追踪：基于 cgroups 的精确进程树追踪，从根本上解决了 PID 文件机制的不可靠问题。
• 安全特性：systemd 原生集成了命名空间隔离、能力限制、系统调用过滤等现代安全加固手段。
• 统一管理：systemctl、journalctl 等工具提供了服务、日志、系统状态的一致性管理接口。

6.2 进阶学习方向

1. 容器集成：探索 systemd-nspawn 以及 systemd 如何与 Podman/Docker 协同工作，管理容器内的服务。
2. 网络与安全：深入研究 systemd-networkd、systemd-resolved 以及更复杂的服务沙箱配置。
3. 资源管理：深入学习 cgroups v2 的所有控制器，实现更精细的 CPU、内存、IO 资源调控。

从 SysVinit 到 systemd 的转变，不仅仅是换一个启动程序，更是一种管理哲学和设计理念的升级。它适应了现代计算基础设施对快速、可靠、可观测和安全的需求。希望这篇对比分析能帮助你在实际工作中更好地理解和运用 systemd，提升运维效率。如果你想与其他开发者交流更多关于 Linux 系统管理的实践经验，欢迎来 云栈社区 分享和讨论。

附录 A：命令速查表

# 服务管理
systemctl start/stop/restart/status <service>
systemctl enable/disable <service>
systemctl daemon-reload

# 日志查看
journalctl -u <service> -f
journalctl -b --no-pager

# 分析工具
systemd-analyze blame
systemd-analyze critical-chain
systemd-analyze security <service>

附录 B：Unit文件关键参数速览

参数	所属段	说明
Type	[Service]	服务类型：simple/forking/oneshot/notify
Restart	[Service]	重启策略：no/on-success/on-failure/always
After	[Unit]	启动顺序依赖
Requires	[Unit]	强依赖关系