Linux 30
← 回目录
13 Week 03 · 服务和进程

journalctl：新时代的看日志方式

Day 03 学了 tail -f /var/log/messages。但 systemd 时代还有另一套日志系统，服务起不来时全靠它。

为什么会有两套日志

先理清关系
两套系统，各管一摊
/var/log/*（rsyslog）
传统方式，纯文本文件。cat、grep、tail 都能直接用。Day 03 学的那套。
journal（systemd）
二进制格式，必须用 journalctl 读。好处是带结构——能按服务、按时间、按优先级精确过滤，不用自己写 grep。
两者关系
大部分系统上两套同时在跑，同一条日志两边都有。但服务启动失败的详细原因，往往只有 journal 里最全。

五条命令

够用了
背这几条
$ sudo journalctl -u nginx              # 只看某个服务
$ sudo journalctl -u nginx -f           # 实时跟踪（等于 tail -f）
$ sudo journalctl -u nginx --since "10 min ago"
$ sudo journalctl -p err -b             # 本次开机以来的错误
$ sudo journalctl -xe                   # ← 服务起不来时看这个

-xe 要背下来

今天最重要的一条

只要 systemctl start 失败，系统提示里就会让你看它：

典型场景
$ sudo systemctl start nginx
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xe" for details.
                                          ↑ 它直接告诉你去哪看
x 和 e 分别是什么
-e
end——直接跳到最新的日志末尾。你关心的永远是刚发生的事。
-x
explain——附上解释性说明，告诉你这条日志是什么含义、可能该怎么处理。
失败原因通常就三类

journalctl -xe 里的报错，九成能归到这三种：① 配置文件语法错　② 端口被占用　③ 权限或 SELinux 不让访问某个文件。

明天的实战课，你会亲手制造第一种并修好它。

按时间过滤

比 grep 精确得多
时间写法很灵活
$ sudo journalctl --since "10 min ago"
$ sudo journalctl --since today
$ sudo journalctl --since "2026-09-07 09:00" --until "2026-09-07 10:00"
$ sudo journalctl -b            # 本次开机以来
$ sudo journalctl -b -1         # 上一次开机的日志 ← 查崩溃原因用这个
-b -1 是查宕机的利器

服务器莫名重启了，想知道它挂之前发生了什么——journalctl -b -1 -p err 直接看上一次开机期间的错误日志。

传统日志翻这个要按时间戳找半天，journal 一个参数搞定。

按严重程度过滤

-p 后面跟级别
$ sudo journalctl -p err        # 只看 error 及以上
$ sudo journalctl -p warning    # warning 及以上

# 级别从严重到轻微：
emerg(0) alert(1) crit(2) err(3) warning(4) notice(5) info(6) debug(7)

巡检时用 journalctl -p err -b --no-pager | tail -30——一眼扫完本次开机以来的所有错误。这条第 28 天写巡检脚本会用到。

组合起来用

四个真实场景
# 1. nginx 刚才为什么起不来
$ sudo journalctl -u nginx -n 50 --no-pager

# 2. 最近 5 分钟有没有报错
$ sudo journalctl -p err --since "5 min ago"

# 3. 边操作边看（Day 03 的两窗口姿势，换成 journal 版）
$ sudo journalctl -u nginx -f

# 4. 谁在 SSH 爆破（journal 版）
$ sudo journalctl -u sshd | grep "Failed password" | tail
--no-pager 的用处

journalctl 默认用分页器（像 less），要按 q 退出。写进脚本时必须加 --no-pager，否则脚本会卡在那等你按键。

日志会不会撑爆磁盘

运维要知道的
看占用、清理
$ journalctl --disk-usage
Archived and active journals take up 208.0M in the file system.

$ sudo journalctl --vacuum-time=7d    # 只保留 7 天
$ sudo journalctl --vacuum-size=200M  # 只保留 200M

journal 默认有上限（一般是磁盘的 10%），不会无限涨。但磁盘紧张时，--vacuum-time 是个能立刻腾出空间的手段——第 21 天讲磁盘满了怎么办时，这是可选招数之一。

今天的面试点

「服务启动失败怎么查？」

「systemctl status 先看概况——它会带出最近几行日志；然后 journalctl -xe 看详细报错。」

「一般能直接定位到三类原因：配置语法错、端口被占、权限或 SELinux 问题。」

能说出这三类，说明你真修过服务。

「服务器昨晚重启了，怎么查原因？」

「journalctl -b -1 -p err，看上一次开机期间的错误日志，重点看最后那段——正常关机和异常宕机在日志里长得不一样。」

今天的练习

敲完再走 · 约 12 分钟
  • sudo journalctl -u nginx -n 30 --no-pager，看昨天启动 nginx 的记录
  • sudo journalctl -p err -b --no-pager | tail -20，看看你这台机器开机以来有没有报错
  • sudo journalctl --since "1 hour ago" --no-pager | tail -20，练时间过滤
  • 两窗口练习：A 窗口 sudo journalctl -u nginx -f，B 窗口 sudo systemctl restart nginx，看 A 窗口实时滚出来
  • journalctl --disk-usage，看日志占了多少空间
  • sudo journalctl -b -1 --no-pager | tail -20（如果这台机器重启过），看上一次开机的日志
明天是重头戏

Day 14：自己把 nginx 配置改坏，再靠日志修回来。

这是整个 30 天里最有价值的一天——把 Day 03、12、13 学的东西串成一次真实的排障。走通这一次，你就真的会排障了。

← 上一天
Day 12 · systemctl