Linux 服务出问题先别重启：用 journalctl 读懂系统日志

服务突然起不来，很多人第一反应是重启服务器。重启常常能暂时掩盖问题，却也把现场清掉了：下次再出同样的问题，还是只能靠猜。更稳的做法是先看日志，而在用 systemd 的系统上，journalctl 就是最顺手的入口。

先从最直接的命令开始：journalctl -u nginx -n 100 只看 nginx 这个单元最近的 100 行。如果服务刚挂掉，加上 --since "10 minutes ago" 能把范围收窄到出事前后，避免在一堆旧日志里翻找。想持续盯着输出，就用 -f，效果和 tail -f 类似，服务一有新日志立刻能看到。

日志太多时要学会过滤。按优先级过滤很实用：journalctl -p err -b 只看本次启动以来的错误级别及以上日志，warning 和 info 先放一边；-b -1 则看上一次启动的日志，适合排查“重启后问题消失了，但想知道重启前发生了什么”的场景。还可以按时间组合，比如 journalctl -u nginx --since today -p warning，只看今天的警告。

只看时间还不够，经常需要把日志和别的线索对上。服务起不来时，除了 journalctl，还可以同时看两处：一是 systemctl status nginx 里的最后几行，它会直接给出退出码和简短原因；二是配置文件本身，改错一个分号、写错一个路径，日志里往往只写“failed to load configuration”，具体错在哪一行还得靠 nginx -t 这类配置检查命令。日志告诉你“什么时候、哪个单元出了什么错”，配置检查告诉你“错在文件哪里”，两者配合才完整。

还有一个容易被忽略的点：磁盘满了也会让日志“说谎”。journald 默认会限制日志占用的空间，磁盘紧张时旧日志可能被轮转掉，查不到出事时的记录。所以排查时顺手看一眼 df -h 和 journalctl --disk-usage，如果日志空间已经吃紧，先清理再谈定位，否则可能在缺失的现场里白找半天。

养成习惯后，排障顺序可以固定下来：先 systemctl status 看状态和退出信息，再 journalctl -u <服务名> --since 锁定时间段，必要时按级别过滤，最后结合配置检查命令确认根因。修好之后不要急着关终端，跑一次 journalctl -u <服务名> -f 确认服务正常输出、没有新的报错，才算真正闭环。

重启不是不能用，而是应该放在定位之后：先看懂日志，再决定是改配置、清磁盘还是重启服务。这样每一次故障都会留下一条可复现的排查路径，下次再遇到类似问题，十分钟就能定位，而不是再重启一次碰运气。