journalctl是排查Linux服务启动失败的核心工具，需按顺序查状态、确认日志持久化、聚焦服务全链路日志、关联系统上下文，并精准锁定时间窗口。
遇到服务异常，别急着重启。journalctl 能帮你还原整个故障过程，关键在于按顺序查、分层次看、带上下文读。
先确认服务状态和日志可追溯性
执行 systemctl status 服务名（如 systemctl status nginx.service），看是否显示 failed 或 inactive；末尾红字是线索，但只是结果。接着检查日志是否能回溯：
- 运行
ls -A /var/log/journal/，非空说明已启用持久化；若为空或提示No journal files were found，需执行sudo mkdir -p /var/log/journal && sudo systemctl restart systemd-journald - 用
journalctl --list-boots查看有多少次启动记录；若只有一条，说明历史日志不可用，得先配持久化
聚焦服务自身启动与崩溃全过程
不要只看最后一行报错，要还原服务从加载到失败的完整链条：
- 查最近一次启动中该服务的所有日志：
journalctl -u 服务名 -b --no-pager - 只看错误及以上级别：
journalctl -u 服务名 -b -p err - 定位启动失败前的关键动作：
journalctl -u 服务名 -b --no-pager | grep -A 3 -B 3 "Starting\|failed\|timeout\|denied"，前后几行常含真正原因（如配置路径错、端口被占、用户不存在）
关联系统级上下文交叉验证
很多服务失败不是自身问题，而是依赖或底层环境异常：
- 查本次启动所有 error 级日志：
journalctl -b -p err，快速发现网络未就绪、时间未同步、OOM killer 杀进程等根因 - 单独看内核事件：
journalctl -k -b或dmesg -b，确认是否有驱动异常、硬件报错、内存不足痕迹 - 验证关键目标单元是否就绪：
journalctl --unit=network.target --unit=multi-user.target -b，若 network.target 没 ready，很多服务会超时退出
锁定时间窗口精准复现问题
对部署失败、定时任务异常或偶发崩溃，靠“最近”太模糊，要精确到分钟甚至秒：
- 操作前记下时间：
start=$(date -Iseconds)，操作后立即执行：journalctl --since="$start" --until="$(date -Iseconds)" -u 服务名 -p err > debug.log - 若不确定服务名，先用
systemctl list-units --type=service --state=failed列出刚失败的单元 - 支持多服务联合排查：
journalctl -u sshd.service -u docker.service --since "2026-07-06 15:20" --no-pager
不复杂但容易忽略
