排查服务依赖冲突需聚焦 systemd 启动链条，用 journalctl 锚定失败时间点日志，识别“dependency failed”等信号，结合 list-dependencies 与 systemctl status 交叉验证依赖状态，并区分 requires（硬依赖）、wants（软依赖）和 after（仅顺序）的影响。

排查服务依赖冲突，关键不是只看目标服务本身报错，而是顺着 systemd 的启动逻辑，看清“谁没起来”“谁被跳过”“谁在阻塞”。journalctl 是唯一能实时还原这一链条的工具。

聚焦失败时间点，缩小日志范围

systemctl status 会显示失败时间戳（如 Jun 11 17:22:34），立刻用它锚定日志窗口：

• 执行 journalctl -xe --since="2026-06-11 17:22:30" --until="2026-06-11 17:22:40"，把范围缩到失败前后 10 秒内
• 避免被大量无关日志干扰，确保看到的是真实启动上下文
• 若时间不准，可先用 journalctl -b -u your-service --no-pager | tail -n 20 快速定位最后几行失败线索

识别典型依赖失败信号

依赖冲突不会直接写“依赖冲突”，而是以特定模式暴露：

Free Ride - Unlimited free AI

一款AI工具，主要用于管理 OpenClaw 所使用的来自 OpenRouter 的免费 AI 模型。自动按质量对模型进行排序，配置回退机制以应对速率限制，并更新 opencla...，适合需要提升相关任务效率的用户。

下载

• “Dependency failed. Refusing to start.” —— 后面必紧跟着某单元状态，例如 “Unit network-online.target is inactive (dead)”
• “Unit xyz.service not found” —— 表示 Requires 或 Wants 的单元文件根本不存在
• “Unit xyz.service is masked” 或 “ConditionPathExists=… was not met” —— 单元被显式禁用或预检不通过，根本不会触发加载
• 无任何日志输出的依赖单元 —— 在同一时间窗口里完全找不到它的 Starting/Started 记录，说明它甚至没进入启动队列

交叉验证依赖关系与实际状态

光看日志不够，必须和 unit 定义、当前状态对齐：

• 运行 systemctl list-dependencies --all your-service.service，查看所有正向依赖（包括间接依赖）
• 运行 systemctl list-dependencies --reverse --all your-service.service，确认是否有 target 或其他服务把它当作必要组件
• 对每个可疑依赖单元，逐个查状态：systemctl status xyz.service，重点看 Loaded 行是否有效、Active 是否为 inactive 或 failed
• 用 systemctl cat your-service.service 检查 [Unit] 段中 Requires=、After=、Wants= 的拼写和命名是否准确

区分硬依赖与软依赖的影响

不是所有依赖都会导致启动中断：

• Requires= 是硬依赖：只要它失败或未激活，目标服务一定无法启动
• Wants= 是软依赖：即使它失败，目标服务仍可能继续启动（但常伴随 warning）
• After= 仅控制顺序，不触发启动 —— 若你只写了 After=network.target 但没写 Wants= 或 Requires=，网络没就绪时服务照样会提前启动并因 DNS 超时失败