Linux systemd-analyze dot 怎样导出 unit 依赖图

排查 systemd unit 关系时，systemd-analyze dot 的作用是把当前管理器可见的依赖输出为 Graphviz dot 文本，再交给 dot 生成 SVG。它适合回答“谁依赖谁、哪些 unit 处在同一关系图里”，不负责回答“哪个服务启动最慢”。默认输出同时包含排序依赖和需求依赖，图太大时应先筛选。

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

最小判断：先用 systemd-analyze dot 导出关系，再用 Graphviz 渲染；需要启动耗时就改用 critical-chain、blame 或 plot。

先看清 dot 输出和 unit 关系

systemd-analyze dot 输出的是文本描述，不是图片文件。图中的节点是 unit，连线表达 systemd 记录的关系；没有传入筛选条件时，输出可能很大。它把“依赖关系”放在结构层面，适合确认 target、service、socket 等 unit 之间的连接。

这里要留意两个容易混淆的词：ordering 说明启动或停止的先后约束，requirement 说明 unit 之间的需要、想要或冲突关系。两者不是同一个维度，默认合在一张图里时，读图要结合图例和命令参数。

把 dot 文本渲染成可保存的 SVG

准备 Graphviz 后，可以把原始 dot 和 SVG 分开保存。这样以后发现图太密时，还能回到文本重新筛选，不必从 SVG 反推命令：

# 保存原始依赖描述，便于后续复查筛选条件。
systemd-analyze dot > systemd-dependencies.dot

# 让 Graphviz 的 dot 程序把文本关系图渲染为 SVG。
dot -Tsvg systemd-dependencies.dot > systemd-dependencies.svg

如果只需要一次管道处理，也可以使用 systemd-analyze dot | dot -Tsvg > systemd.svg。文章中的 SVG 是命令输出的目标格式，不代表已经在某台机器上实际生成；生产排查时应把原始 dot 文件与筛选参数一起归档。

用筛选参数缩小关系图

全量关系图通常不适合直接阅读。可以在命令末尾给出 glob 风格的 pattern，只保留来源或目标节点命中的边；也可以用两组 pattern 分别限定边的起点和终点：

# 只观察名称以 app- 开头的 unit 相关关系。
systemd-analyze dot 'app-*' > app.dot

# 只保留排序关系，排除 requirement 关系带来的视觉噪声。
systemd-analyze dot --order 'app-*' > app-order.dot

# 只观察 target 到 target 的关系，便于看目标层级。
systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' > targets.dot

--order 与 --require 是两种不同的观察角度：前者聚焦排序约束，后者聚焦需求关系。pattern 是筛选输入，不是给 unit 改名；如果筛选后仍然很密，应继续缩小命名范围，而不是把 SVG 当成启动时间线。

依赖图和启动耗时不要混用

因此，看到某个 unit 在 dot 图中连线很多，只能说明关系复杂，不能直接推出它启动最慢。要定位启动瓶颈，应把依赖结构与 critical-chain 或 blame 的结果分开解释。

相关问题

为什么导出的 dot 文件不能直接当 SVG 打开？

dot 是 Graphviz 的文本描述格式，浏览器需要 SVG、PNG 等渲染结果。先保存 dot，再运行 dot -Tsvg 转换即可。

什么时候不该使用 systemd-analyze dot？

如果问题是启动慢、某个服务耗时高或启动链等待，应优先看 critical-chain、blame 或 plot；dot 更适合确认静态关系和筛选依赖范围。