journalctl是排查系统问题的核心工具，通过持久化日志、按启动会话、服务、时间窗口及内核事件多维度回溯，精准定位异常根因。
遇到服务异常、部署失败或系统崩溃，别急着重启或重装。journalctl 的历史日志就是你的“时间回放器”，只要日志持久化启用且未被清理，就能精准定位问题发生前后的关键线索。
确认日志是否可回溯
- 检查
/var/log/journal/目录是否存在且非空：ls -A /var/log/journal/ - 查看当前日志磁盘占用和保留策略：
journalctl --disk-usage和journalctl --vacuum-time=1d --dry-run - 若目录为空或提示
No journal files were found.，说明日志未启用持久化，需先配置Storage=persistent并重启systemd-journald
按启动会话回溯（最常用）
系统每次启动都会生成独立日志会话，适合排查启动失败、服务未加载、内核模块缺失等问题：
- 当前启动全部日志：
journalctl -b - 上一次启动日志（如刚重启过）：
journalctl -b -1 - 倒序查看最新 30 行错误：
journalctl -b -1 -p err -n 30 -r - 过滤启动阶段典型失败关键词：
journalctl -b -1 --no-pager | grep -i "failed\|timeout\|denied\|oom\|segfault"
按服务+时间窗口精准定位
部署失败或某服务突然中断时，不能只看“现在”，要锁定“出问题那几分钟”：
- 先记录部署起始时间戳：
start=$(date -Iseconds) - 执行操作后检查退出码，失败则立即提取：
journalctl --since="$start" --until="$(date -Iseconds)" -u nginx.service -p err -o short-iso > deploy-debug.log - 若不确定服务名，用
systemctl list-units --type=service --state=failed快速列出最近失败单元 - 可叠加多个
-u参数：journalctl -u sshd.service -u docker.service --since "2026-06-09 14:30"
补充内核与底层事件线索
用户空间日志有时掩盖了真正根因，需交叉验证：
- 单独提取内核环缓冲区（含硬件、驱动、OOM killer等）：
journalctl -k -b -1或dmesg -b -1 - 查看 systemd 基础设施就绪状态：
journalctl --unit=network.target --unit=multi-user.target -b -1 - 搜索低级崩溃信号：
journalctl -b -1 --grep="segfault\|trap\|panic\|call trace"
恢复已轮转但未删除的日志（崩溃后）
Ubuntu 等系统断电后 /run/log/journal/ 清空属正常，只要 /var/log/journal/ 分区完好，旧日志仍在：
- 用 Live USB 启动，只读挂载原根分区：
sudo mount -o ro,noatime /dev/sda2 /mnt/recovery - 指定目录离线读取：
journalctl --directory /mnt/recovery/var/log/journal/ -b -2 - 导出指定会话全部日志：
journalctl --directory /mnt/recovery/var/log/journal/ -b -2 --no-pager > boot-b2.log
不复杂但容易忽略
