journalctl 查日志：服务起不来时先看这三条命令

服务突然起不来、接口 502、定时任务没跑——很多新手第一反应是重启服务器，或者到处翻配置文件。其实 systemd 已经把日志都记好了，用 journalctl 几条命令就能定位到报错那一行，比盲目重启省事得多。

先看服务自己的日志

sudo journalctl -u nginx -n 100 --no-pager

-u 指定服务名，-n 100 只看最近 100 行，--no-pager 让输出直接打出来、不进翻页器，方便复制到别处查。

如果服务刚挂掉，想看它最后一次运行的完整记录，可以加 --since "10 minutes ago"，只看最近 10 分钟：

sudo journalctl -u nginx --since "10 minutes ago" --no-pager

时间范围是最实用的过滤器：日志量一大，先把窗口缩到故障发生前后，噪音立刻少一大半。

只看报错级别

日志里 INFO 一大堆，真正有用的是 ERROR 和 WARNING。用 -p 按优先级过滤：

sudo journalctl -u nginx -p err --no-pager

-p err 只显示错误及以上级别。常见的组合是先 -p err 看有没有致命报错，再放宽到 -p warning 看警告——很多“偶尔失败”的毛病，警告里早就写了原因，比如磁盘快满、连接数打满、证书快过期。

跟踪实时日志

服务正在跑、问题正在复现的时候，用 -f 实时跟踪，和 tail -f 一个用法：

sudo journalctl -u myapp -f

一边在另一个窗口触发请求，一边看日志滚动，报错出现的时间点和请求时间点一对上，问题范围就缩得很小了。定位完按 Ctrl+C 退出。

一个排查顺序

服务起不来时，我习惯按这个顺序走：

1. systemctl status <服务名>：先看它到底是没启动、启动失败，还是启动后又退出了，顺带看最后几行日志摘要。
2. journalctl -u <服务名> -p err --since "30 minutes ago"：看最近半小时的报错。
3. 根据报错关键字再决定：是端口被占（Address already in use）、配置文件写错（failed to load 一类）、还是权限问题（Permission denied）。

这个顺序的好处是每一步都在缩小范围，而不是一上来就改配置、重启服务——改配置之前先知道错在哪，改完再用 journalctl -f 验证一次，确认报错消失，才算修完。

小提醒

journalctl 默认只看当前启动以来的日志。如果机器重启过、想查上一次启动的记录，可以加 -b -1 看上一次启动的日志。不过对大多数日常排查来说，先掌握 -u、-p、--since、-f 这四个参数，就已经能覆盖八成场景了。

下次服务出问题，先别急着重启：journalctl 问一句，日志自己会把答案说出来。