排查服务启动死锁需先用systemctl status和journalctl定位卡在activating状态的服务及依赖失败原因，再通过list-dependencies正反向检查循环依赖，最后核查unit文件中Wants/After缺失、DefaultDependencies=no误用或Type配置不当等硬伤。
排查服务互相等待导致的启动死锁，核心是识别 systemd 启动图中隐含的循环依赖或缺失的强依赖关系——它不是传统进程级死锁，而是单元（unit）加载与激活阶段的顺序僵局。
看状态和日志定位卡点
先确认哪个服务卡在 activating 状态：
- 运行 systemctl status myservice.service，观察 Active: 字段是否为 activating (start)，并留意 Loaded 行末尾是否有 “(Start) timed out” 或 “dependency failed” 提示
- 查实时日志：journalctl -u myservice.service -n 100 --no-pager，重点找 “Connection refused”、“failed to connect”、“timeout”、“waiting for” 类错误——这些往往暴露它在等一个还没起来的服务
- 对比目标依赖服务状态：systemctl is-active postgresql.service 或 systemctl status postgresql.service，确认它是否真的没启动、已失败，还是根本没被拉起
查依赖图验证是否成环
systemd 拒绝加载带循环依赖的单元，但有时隐式依赖（如通过 Wants= 间接引入）可能绕过静态检查，导致运行时卡住：
- 正向查：systemctl list-dependencies myservice.service，看它明确 Wants/Requires 哪些服务
- 反向查：systemctl list-dependencies --reverse myservice.service，看哪些服务反过来依赖它——若发现 A Wants=B 且 B Wants=A，就是典型隐式循环
- 追到底层 target：systemctl list-dependencies --all myservice.service | grep -E "(multi-user|basic|network)"，确认它是否意外挂到了 late-start 阶段（比如漏了 Wants=network.target）
检查 service 文件配置硬伤
90% 的“启动等死”源于 unit 文件写法错误，而非逻辑复杂：
- After= 不等于依赖：只写 After=postgresql.service 而不写 Wants=postgresql.service，systemd 不会主动启动 PostgreSQL，myapp 就会一直等连接失败
- DefaultDependencies=no 是雷区：加了这行却没手动补 Before=multi-user.target 或 Wants=network.target，服务可能被丢到启动末尾甚至跳过
- Type 设置不当：用 Type=simple 但应用实际 fork 到后台（如加了 & 或 daemon()），systemd 会误判为已就绪，后续依赖服务提前启动，造成错位等待
模拟启动链验证修复效果
改完配置别急着 reboot，用隔离方式验证：
- 重载配置：sudo systemctl daemon-reload
- 手动触发启动链：sudo systemctl start myservice.service，观察是否秒启成功
- 强制重启依赖链：sudo systemctl restart postgresql.service myservice.service，确认无延迟
- 如果仍卡住，加调试开关：systemctl show myservice.service | grep -E "(Wants|After|Type|ExecStart)"，比对实际生效配置与你编辑的内容是否一致
