排查连锁故障需拉通多服务日志，优先用 journalctl 多 -u 参数按时间合并查看；再通过 _PID 和 _SYSTEMD_UNIT 等字段关联上下文；结合 -b 限定本次启动，并辅以 loginctl 和 systemctl 分析会话与依赖。
查一个服务报错，经常不是单点问题，而是多个服务相互影响导致的连锁故障。比如数据库连不上，可能因为网络服务没起来，或者证书服务先失败了；又或者某个依赖的 socket 没激活，导致主服务启动时直接退出。这时候只看单一服务的日志，容易漏掉真正源头。
按时间窗口拉通多个服务日志
最常用也最有效的方式，是用同一时间范围把几个关键服务的日志并列查看。journalctl 支持同时指定多个 -u 参数，它会自动按时间戳合并排序：
-
查最近10分钟内 nginx + postgresql + redis 的全部日志：
journalctl -u nginx.service -u postgresql.service -u redis.service --since "10 minutes ago" -
聚焦错误级别，缩小干扰：
journalctl -u app.service -u db.service -p err --since "2026-07-07 08:30:00" --until "2026-07-07 08:45:00"
用 _SYSTEMD_UNIT 和 _PID 关联上下文
当某个服务崩溃时，它的子进程、依赖单元或触发它的上游服务，往往共享相同的启动批次或进程树。journalctl 可以通过结构化字段反向追踪：
- 先从失败服务里找出关键报错行里的 PID（比如
Failed to bind port 8080: Address already in use后面通常带 PID），再查这个 PID 的完整生命周期：journalctl _PID=12345 - 查某次启动中所有被 app.service 拉起的单元（包括依赖、socket、timer）：
journalctl _SYSTEMD_UNIT=app.service _SYSTEMD_INVOCATION_ID=xxx（invocation ID 可从systemctl show app.service | grep Invocation获取）
结合启动批次（boot）做横向比对
系统重启后，所有服务都在同一个 boot session 中启动。用 -b 参数能排除历史残留干扰，让关联更干净：
- 查本次开机后所有失败的服务：
journalctl -b --field=UNIT --field=MESSAGE | grep 'failed\|exit-code' | head -20 - 对比两个关键服务在本次启动中的时间线：
journalctl -b -u api.service -u auth.service --no-pager | grep -E '(started|failed|exited)'
用 loginctl 或 systemctl 确认会话与依赖关系
有些错误发生在用户会话层或依赖链上，单纯看 journal 日志不够直观：
- 查当前登录用户的会话 ID：
loginctl list-sessions --no-legend | awk '{print $1}'，再查该会话下所有服务：journalctl _SESSION=c1 - 确认服务依赖关系：
systemctl list-dependencies --reverse app.service，然后针对性地查这些上游单元的日志
