Linux journalctl 如何只看本次启动日志：-b、时间过滤与字段核对

排查 Linux 服务重启后为什么又报错时，最容易踩的坑是直接翻整份 journal。正确的起点通常是 journalctl -b：它把范围收窄到当前这次启动，再配合 --since、--until 和字段过滤，才能判断问题究竟发生在本次启动还是旧日志里。

先用 journalctl -b -p warning..alert 看本次启动的告警，再用服务名、时间和单条字段核对；不要把上一轮启动的错误直接算到当前故障上。

先把日志边界改成当前启动

journalctl 不加参数时可能返回很长的历史记录。当前机器刚重启过，建议先执行：

journalctl -b
journalctl -b -p warning..alert

第一条看完整的本次启动，第二条只保留从 warning 到 alert 的记录。这里的“本次”由 journald 记录的启动 ID 决定，不是简单按今天零点切分。

为什么只看严重级别仍然不够

严重级别适合做第一轮筛选，但驱动初始化、网络切换或服务依赖失败可能只记成 notice 或 info。如果只看 warning，可能错过真正解释故障的前置事件。

更稳妥的顺序是先看服务本身的完整记录，再把级别筛选当作交叉检查：

journalctl -b -u ssh.service --no-pager
journalctl -b -u ssh.service -p err..alert --no-pager

不同发行版的服务单元名可能不同，先用 systemctl list-units --type=service 或服务安装文档确认单元名称。若命令提示没有该单元，不要把它误读成“本次启动没有日志”。

时间过滤和启动过滤怎么叠加

知道故障发生在启动后的某个窗口时，可以把启动边界和时间边界同时写上：

journalctl -b --since "10 minutes ago" --no-pager
journalctl -b --since "2026-08-26 21:40:00" --until "2026-08-26 21:50:00"

第一条适合现场快速观察，第二条适合复盘记录。需要跨时区协作时，在记录中注明主机时区，并优先使用带明确偏移量的时间，避免把客户端时间当成服务器时间。

从输出字段确认到底是谁报错

一行日志里的服务名、进程号和消息正文承担的作用不同。可以用短格式快速查看字段，也可以直接筛选 systemd 单元：

journalctl -b -o short-precise -u ssh.service
journalctl -b _SYSTEMD_UNIT=ssh.service -o json-pretty
journalctl -b _PID=742 --no-pager

旧命令迁移到一套可复查的最小流程

如果过去习惯先执行 journalctl | grep error，可以改成下面这组更容易复盘的命令。它们每一步都保留了边界或证据：

# 1. 当前启动的严重记录
journalctl -b -p warning..alert --no-pager

# 2. 锁定目标服务
journalctl -b -u your-service.service --since "15 minutes ago" --no-pager

# 3. 找到一条可疑记录后核对结构化字段
journalctl -b _SYSTEMD_UNIT=your-service.service -o json-pretty | less

这里的 your-service.service 只是占位符，实际执行前替换成真实单元名。输出中若能看到同一启动 ID、同一服务单元和连续时间戳，结论才有足够依据。

最小验证：重启后如何证明范围没有错

取当前启动与上一启动各看一条边界信息：

journalctl --list-boots
journalctl -b 0 -n 5 --no-pager
journalctl -b -1 -n 5 --no-pager

--list-boots 会列出启动序号、启动 ID 和时间范围；-b 0 与 -b -1 明确指定当前和上一轮。若两个范围的时间戳与机器实际重启时间对不上，先检查 journald 持久化和主机时间，再继续判断服务问题。

常见问题

journalctl -b -1 是不是查看昨天的日志？

不一定。它表示上一次启动，可能是几分钟前，也可能跨过了昨天。准确时间应以 --list-boots 的起止时间为准。

为什么 journalctl -p err 看不到服务错误？

服务可能把关键线索记为 warning、notice 或 info，也可能写入了不同的单元。先去掉级别过滤并加上 -u，再按时间和字段回看。

可以只用 grep 搜索 ERROR 吗？

可以做临时搜索，但它只匹配正文文本，无法替代启动边界、服务单元和 PID 核对。排障结论最好保留原始 journalctl 命令。

把 -b、时间范围和结构化字段放在同一条排查链里，日志就从“很多红字”变成了可验证的启动事件。先确认范围，再解释消息，通常比继续扩大 grep 关键词更快。