排查 systemd 循环依赖需检查 requires/wants 与 after/before 组合形成的闭环，用 systemctl list-dependencies --reverse 追踪依赖路径、systemd-analyze verify 检测硬冲突、systemd-analyze dot 可视化分析，并通过解耦、引入中间 target 或改 requires 为 wants 加运行时检查来修复。
排查开机启动项中的循环依赖，关键在于识别 systemd 单元之间互相 Requires= 或 Wants= 对方，又通过 After=/Before= 强制顺序，最终形成闭环。这种依赖环会导致服务无法启动，systemd 会直接报错并中止初始化流程。
用 systemctl 检查显式声明的循环依赖
systemd 不会自动运行时检测循环依赖，但会在加载单元时静态校验并拒绝启动。排查需主动展开依赖图：
- 执行
systemctl list-dependencies --all --reverse .service，看哪些服务把它列为Requires=或WantedBy=目标；再对这些“上游”服务重复检查，追踪路径是否绕回原服务 - 用
systemd-analyze verify .service验证单个单元文件语法和基础依赖逻辑，它能提前发现Requires=A.service且 A.service 中又Requires=本服务的硬冲突 - 若怀疑某个 target（如
multi-user.target）卷入循环，运行systemd-analyze dot | grep -E "(A\.service.*B\.service|B\.service.*A\.service)"，配合dot -Tpng可视化全图（需安装 graphviz）
关注常见易出循环的配置模式
以下写法看似合理，实则高风险：
-
[Unit]节中同时写Requires=network.target和Wants=myapp.socket，而myapp.socket单元又Requires=myapp.service，myapp.service又反向Wants=myapp.socket—— socket 激活模式下极易隐式成环 - 自定义 target（如
mygroup.target）被多个服务WantedBy=，同时又在这些服务的After=中互相引用，未设统一锚点 - 使用
systemctl edit --full修改已有服务时，误加了双向Requires=，而原单元文件已含反向依赖
从日志和失败现象反推
循环依赖触发时，systemd 不会逐条提示谁依赖谁，而是表现为：
-
systemctl status显示activating (auto-restart)后迅速变为inactive (dead)，无具体错误码 -
journalctl -b -p err出现类似Found ordering cycle on basic.target/start或Job for xxx.service canceled because of a dependency loop - 执行
systemctl daemon-reload后立即报错："Failed to load configuration files: Unit name xxx.service is not valid"，说明解析阶段已识别到结构矛盾
修复与预防建议
打破循环不靠删依赖，而靠解耦或引入中间锚点：
- 把强耦合的两个服务合并为一个单元（如果业务逻辑允许），或拆出共用的
.target作为启动协调点 - 将
Requires=改为Wants=，再用ExecStartPre=或ExecStartPost=做运行时健康检查，避免启动期硬依赖 - 对网络服务依赖，优先用
After=network-online.target+Wants=network-online.target，而非直接Requires=其他服务 - 所有自定义单元文件写完后，先运行
systemd-analyze verify *.service再enable
