查服务启动问题需结合 journalctl 日志与依赖分析：先用失败时间戳精确定位日志窗口，识别“dependency failed”等信号；再通过 systemctl list-dependencies 和 status 交叉验证依赖单元状态及 unit 文件配置，区分 requires（硬依赖）、wants（软依赖）和 after（仅顺序）的实际影响。
查服务启动顺序和依赖问题，不能只盯着目标服务本身，得顺着 systemd 启动链条往下看。journalctl 是唯一能还原真实启动上下文的工具，它把“谁先起、谁卡住、谁被跳过”全记下来了。
聚焦失败时间点，精准定位日志窗口
systemctl status 会显示服务失败的具体时间戳，比如 Jul 08 14:22:15。立刻用这个时间锚定 journalctl 查询范围：
- 执行
journalctl -b -u your-service --since="2026-07-08 14:22:10" --until="2026-07-08 14:22:20"，把日志缩到失败前后 10 秒内 - 如果时间不准，先运行
journalctl -b -u your-service --no-pager | tail -n 20快速扫最后几行，找关键线索 - 避免直接翻完整日志——大量无关条目会掩盖真正阻塞点
识别依赖失败的典型信号
systemd 不会直接写“依赖冲突”，但会在日志里留下明确痕迹：
- “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 记录，说明它甚至没被 systemd 调度
交叉验证依赖定义与实际状态
光看日志不够，必须结合 unit 文件和当前系统状态确认：
- 运行
systemctl list-dependencies --all your-service.service，列出所有正向依赖（含间接依赖） - 运行
systemctl list-dependencies --reverse your-service.service，确认是否有其他服务或 target 把它当必需组件 - 对每个可疑依赖单元，逐个执行
systemctl status xyz.service，重点看 Loaded 是否有效、Active 是否为 inactive 或 failed - 用
systemctl cat your-service.service检查 [Unit] 段中 Requires=、Wants=、After= 的拼写和命名是否准确
区分 Requires、Wants 和 After 的实际影响
不是所有依赖都会让服务彻底起不来：
- Requires= 是硬依赖：只要它失败或未激活，目标服务一定无法启动
- Wants= 是软依赖：即使它失败，目标服务仍可能继续启动，但通常伴随 warning 日志
-
After= 只控制顺序，不触发启动——比如只写
After=network.target却没加Wants=network.target，网络服务根本不会被拉起，你的服务就可能因无网络而超时失败
