用 journalctl 快速定位服务故障：从报错时间倒推问题

服务挂了、接口 500 了，先别急着重启碰运气。systemd 的日志都在 journalctl 里，按时间倒推，往往几条命令就能锁定是配置错了、依赖没起来，还是资源被耗尽了。

一、先看最近的报错，别从头翻日志

journalctl -u nginx -n 100 --no-pager
journalctl -u nginx -p err -n 50 --no-pager

-u 指定服务，-n 只看最后若干行，-p err 只看错误及以上级别。服务刚挂掉时，先看最后 100 行，大多数故障的直接原因就在这里：端口被占、配置文件语法错、依赖的数据库连不上，报错原文通常写得很直白。

如果不知道故障发生在几点，先看服务状态里的时间戳，再按时间段查：

journalctl -u nginx --since "2026-11-01 09:00" --until "2026-11-01 09:30" --no-pager

时间范围一收窄，无关日志立刻消失，比全文搜索省事得多。

二、从启动失败倒推：看上一次启动的全过程

服务起不来时，只看报错行可能不够，要看它启动时走到了哪一步：

journalctl -u myapp --since "today" --no-pager | head -n 100

重点看三类信息：第一，启动命令本身有没有报错，比如可执行文件路径错了、参数拼错了；第二，依赖有没有就绪，比如先于数据库启动、网络还没配好；第三，权限有没有问题，比如读不到证书文件、写不了日志目录。启动日志是按顺序的，卡在哪一步，后面的步骤就不会出现，断点就是线索。

配合状态命令一起看更完整：

systemctl status myapp --no-pager

状态页会给出最近几行日志、退出码和主进程 PID，退出码 203 常是可执行文件或工作目录问题，退出码 1 则要回日志里找应用自己的报错。

三、把日志和系统状态对上号

日志里说连接超时、内存不足，别只信一句话，用系统状态交叉验证：

journalctl -p err --since "1 hour ago" --no-pager
free -h
ss -tlnp | grep 8080

内存耗尽时日志里会出现 OOM 相关记录，同时 free 能看到内存见底；端口冲突时日志报地址已被使用，ss 能直接看到占用者。两个来源对得上，结论才站得住；对不上，就说明报错可能是表象，真正的原因还在上游。

还有一个容易忽略的点：日志时间。journalctl 默认按本地时区显示，查跨时区部署的服务时，先确认 timedatectl 的时区设置，否则按北京时间去对 UTC 日志，时间段会错位一整段。

四、一套固定的排查顺序

服务异常：先 systemctl status 看状态和退出码 → 再 journalctl -u 服务 -n 100 看最近报错 → 按报错时间用 --since/--until 收窄 → 看上一次完整启动日志找断点 → 用 free、ss、磁盘使用率交叉验证。按这个顺序走，大多数服务故障不用重启三次就能定位，不用来回猜。

小结

journalctl 的价值不在日志多，而在能按服务、级别、时间三把筛子快速收窄。先看最近报错，再看启动断点，最后和系统状态对上号——定位先于动手，重启只是确认修复的最后一步，不是排查本身。