journalctl -b -1 为何看不到上一轮：从 --list-boots 到持久化目录定位日志去向

服务器重启后执行 journalctl -b -1 却没有结果，问题通常不在“命令失效”，而在两个前置条件没有同时满足：journal 里确实存在上一轮启动，以及上一轮日志曾经保存到磁盘。先运行 sudo journalctl --list-boots 看启动索引，再检查存储目录和 Storage=，比反复改写 -b 参数更快。

先列出启动编号，别直接猜 -1 代表什么

先不要把“上一启动”当作一定存在。--list-boots 会列出相对启动编号、Boot ID，以及该次启动第一条和最后一条日志的时间。用无分页输出更适合保存排查记录：

sudo journalctl --list-boots --no-pager
# 只看当前启动最近 20 行
sudo journalctl -b 0 -n 20 --no-pager
# 尝试读取上一启动
sudo journalctl -b -1 --no-pager

官方定义中，-b 会按 _BOOT_ID 过滤；省略 Boot ID 时，-0 表示最后一次启动，-1 表示再前一次。若列表只有一行，-b -1 没有匹配是正常结果。若列表有多行但命令仍空，再把列表里的完整 Boot ID 复制出来查询，避免相对编号受 --directory 或导入日志影响：

sudo journalctl _BOOT_ID=替换为列表中的完整ID --no-pager
sudo journalctl -b -1 -u ssh.service --since "2026-09-04 08:00" --no-pager

第二条命令只是进一步缩小范围：只有在上一启动确实存在时，-u 和时间条件才有意义。

再判断旧日志有没有真正落盘

启动编号存在，只说明当前可访问的 journal 文件里记录过多次启动，不等于所有机器都已启用持久化。先看目录：

sudo ls -ld /var/log/journal /run/log/journal 2>/dev/null
sudo grep -R "^[[:space:]]*Storage=" /etc/systemd/journald.conf /etc/systemd/journald.conf.d 2>/dev/null

按官方配置说明，Storage=volatile 只把日志放在内存下的 /run/log/journal；Storage=persistent 优先使用磁盘上的 /var/log/journal，磁盘不可写或早期启动阶段才回退到运行时目录；Storage=auto 则由 /var/log/journal 是否存在决定采用持久化还是易失模式。因此，重启后只有当前启动，通常首先检查这里。

图1：先用启动索引确认 -1 对应的 Boot ID 与时间范围，再决定查询条件。

按结果修复查询与持久化设置

可以把现象分成三类处理：列表只有当前启动，说明旧记录当前不可见；列表有旧启动但 -b -1 为空，优先改用完整 Boot ID 并去掉额外过滤条件；列表有旧启动且完整 ID 能查到，问题只是原查询的 unit、时间或权限范围过窄。

需要跨重启保留系统日志时，可使用配置 drop-in，便于升级时单独管理：

sudo install -d -m 2755 /var/log/journal
sudo tee /etc/systemd/journald.conf.d/60-persistent.conf >/dev/null 

--flush 用于把运行时日志转移到持久化存储；它不会凭空恢复已经在上一次重启时丢失的记录。修改后可用 journalctl --disk-usage 观察 journal 文件是否开始占用磁盘，再安排一次受控重启验证。

图2：存储模式决定重启后是否还能找到上一启动的 journal 文件。

用一次回归检查确认修复生效

不要只看配置文件写入成功。先记录当前启动编号，然后产生一条容易识别的测试日志，重启后依次检查：

sudo systemd-cat -t journal-check echo "journal persistence check"
sudo journalctl --list-boots --no-pager
sudo journalctl -b -1 -t journal-check --no-pager

如果看不到测试行，按“启动列表 → 目录 → Storage= → 权限”的顺序回到前面排查。日志保留还受磁盘可写性和轮转策略影响，不能把某次成功查询理解成永久不受限制。

相关问题

为什么 journalctl -b -1 有时比完整 Boot ID 更容易误判？
它依赖当前 journal 集合的相对顺序；先用 --list-boots 确认编号，再用完整 ID 复核最稳妥。

只创建 /var/log/journal 就一定能找回旧日志吗？
不能。它只能为后续持久化提供目录；已经因易失存储或重启丢失的记录无法恢复。

为什么重启后要执行 journalctl --flush？
journald 启动早期可能先使用运行时存储，flush 会在条件满足时把这部分数据切换到持久化位置。

参考：systemd journalctl 手册、systemd journald.conf 手册。