Linux journalctl 按服务和启动轮次筛选日志怎么写

排查“某个服务上一次启动为什么失败”时，最稳妥的写法不是直接翻完整日志，而是先确认启动轮次，再把服务单元和时间范围叠加上去。最常用的组合是 journalctl -u nginx.service -b -1：-u 限定服务，-b -1 指向上一次启动；如果要查当前启动，把 -b -1 换成 -b 即可。

先运行 journalctl --list-boots 确认轮次，再用 journalctl --unit=服务名 --boot=轮次 筛选。多个不同字段会同时生效；--since、--until 和 -n 只负责继续收窄范围。

本文要点：① 相对启动编号要从列表中确认；② --unit 和 --boot 是内容筛选条件；③ 输出格式不会改变筛选结果，权限不足时先解决日志访问权限。

先确认启动轮次，再组合服务过滤

相对编号是从当前已知日志集合推导出来的，不建议凭印象把“上一次启动”写成固定数字。先列出启动记录：

# 先看相对编号、Boot ID 以及每次启动的时间范围
journalctl --list-boots

列表中的 0 通常代表最近一次启动，负数表示更早的启动；如果要把查询结果写进故障单，还可以记录对应的 32 位 Boot ID。确定目标后再筛选：

# 查看上一次启动中 nginx.service 的全部可见日志
journalctl --unit=nginx.service --boot=-1 --no-pager

# 查看某个已知 Boot ID 中的 ssh.service 日志
journalctl --unit=ssh.service --boot=BOOT_ID --no-pager

--unit 不是普通文本搜索，它按 systemd unit 关联的字段匹配；--boot 则把查询限制到指定启动。两者放在一起时，结果是“该服务在这次启动里的日志”，不会把其他启动的同名服务混进来。

按服务、轮次和时间缩小范围

当一次启动持续时间很长时，可以继续加时间窗口、日志条数和优先级。下面这条命令适合先看某次启动中最近的告警：

# 只看上一次启动中 nginx 的 warning 及更严重日志，最多显示 80 行
journalctl --unit=nginx.service --boot=-1 --priority=warning..alert -n 80 --no-pager

如果已经知道故障发生的大致时间，可以改用明确的时间边界：

# 在指定启动内再收窄到一个时间段，并使用带微秒的时间格式
journalctl -u nginx.service -b -1 \
  --since "2026-09-09 09:00:00" \
  --until "2026-09-09 09:15:00" \
  -o short-iso-precise --no-pager

--since 和 --until 是额外的时间条件；-o short-iso-precise 只改变输出展示，适合比较相邻日志的时间关系。需要实时追踪当前服务时可以使用 journalctl -fu nginx.service，但它不适合回看已经结束的启动轮次。

三个容易误判的边界

• 轮次编号不是时间戳。日志被轮转、目录改变或查看另一台机器的日志目录后，相对编号应重新用 --list-boots 确认。
• 服务名要按 unit 写。例如模板服务应使用实际实例名；用户会话服务则考虑 --user-unit，不能只在全文里搜索一个短词。
• 看不到不一定是没有日志。普通用户可能没有访问系统日志的权限，先确认账号的 journal 访问范围，再判断服务是否真的没有输出。

常见问题

只知道服务名，不知道上一次启动编号怎么办？

先执行 journalctl --list-boots，用时间范围和 Boot ID 对照重启时间，再选择对应编号。不要把 -b -1 当成永久不变的“故障启动 ID”。

为什么加了 -u 之后仍然出现 systemd 相关行？

--unit 会把该 unit 的日志以及 systemd 针对该 unit 记录的关联信息纳入匹配范围，这是为了保留服务状态上下文，并不等于过滤失效。

实际排障时可以把最终命令固定成四段：--unit 说明服务，--boot 说明启动轮次，时间或优先级参数说明问题窗口，--no-pager 和输出格式负责让结果便于复制。这样既能避免翻错一轮日志，也方便把同一条查询交给下一位值班同事复用。