用 journalctl 快速定位服务报错

服务在服务器上跑得好好的，突然访问不了，第一反应往往是重启。但重启之前如果不先看日志，等于把唯一的线索亲手删掉。systemd 管理的服务，日志都收在 journal 里，用 journalctl 就能快速定位问题。

先看最近发生了什么

最常用的三条命令：

• journalctl -u nginx -n 100 --no-pager：看某个服务最近 100 行日志。-u 指定单元名，刚出问题时先扫这一段，通常报错就藏在最后几行。
• journalctl -u nginx -f：实时跟踪。和 tail -f 一样，边复现问题边看输出，适合调试偶发故障。
• journalctl -u nginx --since "10 min ago"：只看最近 10 分钟。也可以写 --since "2026-11-03 09:00" --until "2026-11-03 09:30" 精确截取故障时间窗，避免在几万行历史里大海捞针。

按优先级过滤，只看真错误

日志太多时用 -p 按优先级过滤：journalctl -u myapp -p err 只看 error 及以上级别，warning 以下的噪音全部滤掉。如果想看系统级的严重问题，直接 journalctl -p err -b 看本次开机以来的全部错误。

还有两个容易忽略的细节：一是 -b 表示本次启动，服务如果是被系统更新连带重启坏的，用 journalctl -u myapp -b -1 能翻到上一次启动的日志做对比；二是退出码信息，systemctl status myapp 只给最后几行，真正的崩溃堆栈还得回 journal 里找。

日志占盘和保留策略

journal 默认会持续增长，老机器上占几个 G 很常见。先用 journalctl --disk-usage 看占用，再决定处理方式：临时清理用 journalctl --vacuum-time=7d 只保留 7 天；长期则在 /etc/systemd/journal.conf 里设 SystemMaxUse=500M 并重启 systemd-journald，让它自动滚动。注意 vacuum 删的是归档日志，确认近期故障已经看完再执行。

小结

定位故障的顺序应该是：先 status 确认状态，再 journalctl -u 看日志，最后才考虑重启。养成先看日志的习惯，大多数「突然挂了」的问题，五分钟内就能找到真正的报错行。