systemd 服务管理实战：常用命令、故障自愈与日志排查

systemd 已经是 RHEL 8 及以后所有主流发行版的默认初始化系统。本文整理运维中最常用的命令、崩溃自愈配置，以及一条可复用的故障排查路径。本文所有命令均在 Alibaba Cloud Linux 4（systemd 255） 实测通过。

一、状态查询：三个 is-* 命令

systemd 有三个返回「是/否」的命令，容易混淆但用途不同：

# 进程当前是否在运行
systemctl is-active nginx

# 是否配置了开机自启
systemctl is-enabled nginx

# 详细状态（含运行时长、进程 PID、最近日志）
systemctl status nginx

is-active 关心「现在跑没跑」，is-enabled 关心「重启后会不会自己起来」。排查「服务莫名没起来」时，先确认两者状态是否一致——常见问题是 is-active 为 inactive 但 is-enabled 为 enabled，说明是运行期间挂掉了，而非开机配置问题。

status 输出里的 Active: 行最值得关注，它会直接告诉你服务已经连续运行多久：

Active: active (running) since Mon 2026-10-20 13:09:12 CST; 50min ago

如果这个时长明显短于你的预期（比如刚重启服务器却显示只有几分钟），说明服务一直在重启。

二、启动、停止与重载

systemctl start nginx      # 启动
systemctl stop nginx       # 停止
systemctl restart nginx    # 重启（stop + start）
systemctl reload nginx     # 重载配置（不中断进程）

reload 与 restart 的区别很关键。 Nginx、Apache 这类能平滑加载配置的服务，reload 只让主进程重新读取配置并优雅替换 worker，现有连接不会中断。而 restart 会直接杀掉所有 worker，进行中的请求会失败。

改完配置文件后，先验证语法再重载，这是避免服务挂掉的必要步骤：

nginx -t                    # 语法检查
systemctl reload nginx      # 语法通过后再重载

如果服务不支持 reload，用 restart 前务必确认配置正确——restart 失败时代码不会自动回滚，服务就停在那了。

三、开机自启：enable 与 disable

systemctl enable nginx      # 开机自启（立即生效 + 写入配置）
systemctl disable nginx     # 取消开机自启
systemctl enable --now nginx  # 同时启用并立即启动

--now 参数把「配置自启」和「立即启动」合并成一步，是新装服务时最常用的写法。

需要临时屏蔽某个服务（比如误配的第三方服务干扰排查），用 mask：

systemctl mask nginx       # 彻底屏蔽，连 start 都会失败
systemctl unmask nginx     # 解除屏蔽

mask 会创建到 /dev/null 的符号链接，比 disable 更彻底。服务被 mask 后执行 start 会直接报「unit file is masked」错误，不会真的启动。

四、崩溃自愈：Restart 配置

这是生产环境最该配的一项。服务进程意外退出时自动拉起：

[Service]
Restart=on-failure
RestartSec=5s

Restart 的取值有讲究：

推荐用 on-failure：它区分了「正常退出」和「异常退出」。always 有个隐患——手动执行 systemctl stop 时，systemd 也会当作需要重启的场景，必须配合 StartLimitBurst 限制次数，否则服务会陷入无限重启。

重启频率限制（重要）

只配 Restart 不够。如果服务配置有误导致启动即崩溃，它会无限重启刷屏日志，把磁盘塞满。systemd 提供 StartLimitIntervalSec 和 StartLimitBurst 两个参数做限流：

[Unit]
StartLimitIntervalSec=60
StartLimitBurst=5

[Service]
Restart=on-failure
RestartSec=5s

上面这份配置的含义是：60 秒窗口内如果启动失败超过 5 次，服务进入 failed 状态并停止重试。这两行要放在 [Unit] 段而非 [Service] 段，写错位置不生效。

查看重启次数

systemctl show nginx -p NRestarts

这个值持续增长就说明服务在反复重启，直接指向配置问题。配合 -p Restart 和 -p RestartUSec 可以确认当前生效的重启策略：

systemctl show nginx -p Restart -p RestartUSec -p NRestarts

输出示例：

Restart=no
RestartUSec=100ms
NRestarts=0

服务被限流卡住后，解除办法是手动重置计数：

systemctl reset-failed nginx

五、日志排查：journalctl

systemd 把所有服务日志集中交给 journald 统一管理，用 journalctl 检索。

按服务过滤

journalctl -u nginx                 # 查看某服务全部日志
journalctl -u nginx -n 100          # 只看最近 100 行
journalctl -u nginx -f              # 实时跟踪（最常用）

-f 参数在排查「服务刚启动就挂」这类问题时尤其好用，可以一边启动一边观察：

journalctl -u nginx -f &
systemctl restart nginx

按时间过滤

journalctl --since "30 minutes ago"
journalctl --since "2026-10-20 14:00:00" --until "2026-10-20 15:00:00"
journalctl -b                          # 仅本次启动以来的日志

-b 是排查服务启动问题最有用的参数。系统重启后旧日志容易混淆视听，加 -b 只看本次启动的记录：

journalctl -b -u nginx

要翻上一次启动的日志，用 -b -1，这在排查「服务器莫名重启」时是第一步：

journalctl -b -1 | tail -100

按优先级过滤

journald 的日志分 8 个优先级（emerg 到 debug）。排查时用 -p 只看严重级别的：

journalctl -p err              # 只看 error 及以上
journalctl -p warning --since today
journalctl -p crit -b           # 仅本次启动的严重错误

组合过滤与导出

journalctl -u nginx -u php-fpm -p err --since today
journalctl -u nginx --since "1 hour ago" --no-pager > /tmp/nginx-err.log

多个条件是「与」的关系（同时满足）。排查线上问题时导出日志发给技术支持，这个组合最常用。

日志占用检查

journalctl --disk-usage

输出示例：

Archived and active journals take up 54.9M in the file system.

磁盘写满的故障里，日志占满是个常见原因。确认后可以清理：

journalctl --vacuum-size=500M    # 清理到 500M 以内
journalctl --vacuum-time=7d      # 只保留最近 7 天

六、一条可复用的排查路径

把上面的命令串成固定流程，比逐个试命令高效得多：

# 1. 服务是什么状态
systemctl is-active nginx

# 2. 开了多久（判断是否反复重启）
systemctl status nginx | grep Active

# 3. 重启过多少次
systemctl show nginx -p NRestarts

# 4. 本次启动的最近错误
journalctl -b -u nginx -p err -n 50

# 5. 配置是否正确
nginx -t

# 6. 卡在 failed 状态则清计数
systemctl reset-failed nginx

七、常见问题速查

改了配置但不生效

先确认改的是哪个文件：

systemctl cat nginx

这个命令会显示 unit 文件路径、加载的配置片段，以及它实际读到的配置来源。很多「改了没生效」的原因是改错了文件路径。

unit file is masked 错误

服务被 mask 了，执行 systemctl unmask 服务名 解除。

服务启动后立刻退出

journalctl -u 服务名 -n 50 --no-pager

大部分情况下日志里会直接写明原因。配置语法错误通常是主因。

想看开机各服务花了多久

systemd-analyze blame

排查开机慢时定位瓶颈服务。如果结果不够直观，加图形化：

systemd-analyze plot > /tmp/boot.svg

参考文档

• systemctl 手册：freedesktop.org
• journalctl 手册：freedesktop.org
• systemd.unit 配置说明：freedesktop.org

本文命令在 Alibaba Cloud Linux 4（内核 6.6.102 / systemd 255）实测通过。RHEL 8、Rocky Linux 9 等同代发行版同样适用。