登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  linux

Linux journalctl 如何只看某 systemd 服务本次启动日志

来源:17golang原创

时间:2026-09-10 13:47:37 268浏览 收藏

如果只想查看某个 systemd 服务在当前这次系统启动里的日志,直接把服务过滤和启动过滤放在同一条命令中:

# -u 限定服务,-b 限定当前系统启动,--no-pager 便于复制完整输出
journalctl -u demo.service -b --no-pager

demo.service 换成实际 unit 名即可。这里的 -u 对应服务边界,-b 对应系统启动边界,两者是交集关系,不是“先看服务、再凭肉眼挑时间”。

官方资料入口:https://www.freedesktop.org/software/systemd/

要点速览
  • 最小写法是 journalctl -u 服务名 -b --no-pager
  • 空结果优先检查 unit 全名、读取权限和是否为用户服务。
  • 本次系统启动不等于服务最近一次启动;需要历史批次时先看 --list-boots

先确认 unit 名,再组合 -u 与 -b

服务页面上显示的进程名、软件名和 systemd unit 名可能不同。先用状态命令确认精确名称:

# 显示 unit 的实际状态;不要把进程名直接替换成服务名
systemctl status demo.service --no-pager

# 只查看当前系统启动中该服务的日志
journalctl -u demo.service -b --no-pager -o short-iso

-u--unit= 的短选项,会匹配服务相关的 systemd 日志字段;-b 不带参数时表示当前 boot。两个条件同时存在时,journalctl 只保留同时满足服务和启动批次的记录。-o short-iso 让时间格式更适合跨机器比较,若只想看最近 80 行,可以加 -n 80

journalctl 使用 -u 服务过滤和 -b 启动过滤连接 _SYSTEMD_UNIT、_BOOT_ID 与 systemd-journald 的静态边界图
图1:把 -u 的服务边界和 -b 的启动边界叠加起来,理解为什么结果只保留当前服务本次启动的日志。

本次启动不等于最近一次服务启动

一台机器可能经历多次 boot,同一个服务也可能在一次 boot 中被手动重启多次。因此“当前 boot 的服务日志”仍可能包含本次系统启动后的多次服务实例。先查看系统启动列表:

# 列出日志库能够识别的系统启动批次,0 通常代表当前批次
journalctl --list-boots --no-pager

# 只查看目标服务在当前 boot 的最近 30 行
journalctl -u demo.service -b -n 30 --no-pager

如果要看上一次系统启动,可使用 -b -1;这改变的是系统 boot 边界,不是服务名。较新的 systemd 还提供 --list-invocations,可用于观察 unit 的服务实例边界:

# 查看该 unit 的 invocation 记录;先确认本机 systemd 支持此选项
journalctl -u demo.service --list-invocations --no-pager

# 将当前 boot 内的日志再收窄到一个时间窗口
journalctl -u demo.service -b --since "10 minutes ago" --until now --no-pager

排障时先决定要回答哪个问题:机器重启后的服务表现,用 -b;某次服务重启后的表现,用 invocation 或明确的 --since/--until。不要用“最新几行”代替边界选择。

journalctl 的 --list-boots、--list-invocations、BOOT_ID、INVOCATION_ID 与时间范围静态关系图
图2:启动批次、服务实例和时间范围是三种不同边界,比较历史日志前应先确认自己要筛选哪一种。

空结果时按四层检查

现象优先检查处理方式
提示找不到 unit 或没有记录unit 名systemctl list-units --type=servicesystemctl status 确认完整名称。
普通用户看不到系统服务日志读取权限先用 sudo journalctl -u demo.service -b 对比;长期使用可加入系统日志读取组。
服务是用户级 unit日志范围使用 journalctl --user -u app.service -b,不要和系统级 unit 混查。
重启后历史日志消失journald 保存策略检查日志是否持久化;当前日志库没有保存的记录,筛选参数无法补回。

还有一个容易忽视的边界:journalctl 读取的是调用者有权访问的 journal。命令为空不一定代表服务没有输出,也可能只是普通用户看不到系统级日志。先确认权限,再判断服务是否真的没有写日志。

实用命令速查与复查动作

  • 实时跟踪当前 boot 的服务:journalctl -u demo.service -b -f
  • 只看错误级别及以上:journalctl -u demo.service -b -p err
  • 导出便于复制的纯文本:加上 --no-pager -o short-iso,避免分页器截断上下文。
  • 对比上一轮启动:先执行 journalctl --list-boots,再把 -b -1 换入同一条服务过滤命令。

最后复查时,至少确认三件事:unit 名确实对应目标服务;-b 是否表达了你要的系统启动批次;命令执行用户是否有权读取该批次的 journal。这样得到的日志范围才足以支撑后续的重启、配置或依赖排查。

常见问题

为什么 journalctl -u demo 有时也能看到日志?

systemd 可能把不带后缀的名称解析为 unit,但排障记录建议使用完整的 demo.service,可读性和复查一致性更好。

-b-b -1 有什么区别?

-b 选择当前系统启动,-b -1 选择前一个启动批次。它们都可以和 -u 同时使用。

为什么服务刚启动却查不到日志?

先确认 unit 名和权限,再检查服务是否把日志写入其他文件、是否使用了用户级 unit,以及 journald 是否正在接收该进程的输出。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>