Linux systemd-analyze dump 怎样按 unit 过滤服务管理器状态

排查某个服务时，如果只想查看服务管理器保存的 unit 状态，推荐使用 systemd-analyze dump 并在后面加 unit 名称或 glob 模式，例如 systemd-analyze --no-pager dump 'sshd.service'。它输出的是面向人工阅读的服务管理器状态序列化结果，不是启动耗时报告，也不是依赖图。

官方手册：https://www.freedesktop.org/software/systemd/man/latest/systemd-analyze.html

过滤的关键是把 unit 模式放在 dump 后面，并用引号保护通配符；需要查看用户级服务时再加 --user。如果结果要交给脚本长期解析，不要依赖 dump 的文本布局，应改用 systemctl show 查询固定属性。

先确认 dump 查看的是哪一个服务管理器

没有过滤模式时，dump 会输出一个通常很长的服务管理器状态。默认连接 system 实例；同一条命令加上 --user 后，查询对象变为当前用户的 user service manager。排查前先把实例选对，否则“找不到 unit”可能只是看错了管理器。

# 默认查看 system 实例，并关闭分页，便于完整阅读输出
systemd-analyze --no-pager dump

# 查看当前用户的 user 实例，避免把两套 unit 混在一起
systemd-analyze --user --no-pager dump

这一步只解决“状态从哪里来”的问题。dump 适合观察服务管理器内部的整体状态；启动阶段耗时应看其他专用命令，依赖关系也不属于本文的过滤范围。

用 unit 名称或模式缩小状态范围

官方语法允许在 dump 后提供可选的 unit 名称模式。精确排查单个服务时直接写完整 unit 名；同一类服务可以使用 glob。建议给模式加引号，让通配符交给 systemd 处理，而不是先被 Shell 展开。

# 精确查看一个 unit 的服务管理器状态块
systemd-analyze --no-pager dump 'sshd.service'

# 只关注同一前缀的服务，通配符由 systemd-analyze 处理
systemd-analyze --no-pager dump 'worker@*.service'

# user unit 使用相同的过滤思路，但要切换到 user manager
systemd-analyze --user --no-pager dump 'pipewire*.service'

如果模式没有命中，先检查 unit 名称是否写对，再确认它属于 system 还是 user 实例。不要为了“看全”而无条件保存完整 dump：输出可能很长，过滤后的范围更适合现场排查。

按 unit 状态块读取线索，不要假定完整格式

过滤后的结果仍然是面向人的文本。通常可以先找到 Unit 标识，再结合 Description、状态信息和关联字段判断线索。阅读时关注“这个 unit 属于谁、当前呈现什么状态、还有哪些关联信息”，而不是把每一行当成稳定 API。

例如现场查看时可以把输出保存到临时文件，再用普通文本工具定位 unit 名称。下面的命令只用于人工查找，不把结果变成程序接口：

# 保存一个过滤后的人工排查副本，再定位目标 unit 的出现位置
dump_file="$(mktemp)"
systemd-analyze --no-pager dump 'sshd.service' >"$dump_file"
grep -n -A18 -B2 -- 'sshd.service' "$dump_file"
rm -f "$dump_file" # 排查结束后清理临时文件

这里的 grep 只是帮助人快速跳到相关段落，不能据此断言每个 systemd 版本都会有同样的行数、字段顺序或缩进。官方手册明确提示 dump 的输出格式可能变化，不能被应用程序解析。

输出要交给脚本时改用固定属性接口

如果目标是监控、部署脚本或长期兼容的自动化，建议把任务拆开：用 systemd-analyze dump 做一次性人工诊断，用 systemctl show 读取明确的属性。后者可以列出你真正需要的字段，例如 LoadState、ActiveState 和 SubState。

# 脚本读取固定属性，避免解析 dump 的可变文本布局
systemctl show 'sshd.service' \
  --property=LoadState,ActiveState,SubState \
  --no-pager

# user unit 也要让查询端保持同一个实例范围
systemctl --user show 'pipewire.service' \
  --property=LoadState,ActiveState,SubState \
  --no-pager

这样做不是说 dump 没有价值，而是把“观察内部状态”和“读取稳定属性”分成两条边界。前者适合故障现场形成线索，后者适合让程序消费。

三个容易混淆的边界

第一，过滤模式不是 Shell 的文件匹配。模式应该作为参数传给 systemd-analyze；用单引号保护 *，避免当前目录中的文件名改变命令参数。

第二，system 与 user 不是同一套 unit。看到 unit 名并不代表它属于当前正在查询的实例。命令行中的 --user 必须和排查对象保持一致。

第三，dump 不是稳定数据格式。可以读它来定位现场线索，但不要编写依赖字段顺序、固定缩进或固定段落长度的解析器；需要固定属性时使用 systemctl show --property=...。

相关问题

为什么加了 unit 名称仍然看到很多内容？

先确认模式是否真的命中目标，也确认当前查询的是 system 还是 user manager。dump 的输出是服务管理器状态序列化，不等同于只返回一行属性。

能不能用 grep 解析 dump 做监控？

不建议。grep 可以帮助人工定位段落，但官方不保证 dump 输出格式稳定；监控应使用 systemctl show 并显式指定属性。

查看用户服务为什么要加 --user？

system 实例与 user 实例由不同的服务管理器维护。加上 --user 才会把 dump 和查询范围切换到当前用户的服务管理器。