Linux 日志排查：用 journalctl 快速定位服务故障

服务突然起不来、网站间歇性 502、定时任务悄悄失败——Linux 服务器出问题时，第一反应不应该是重启碰运气，而是先看日志。日志里写着故障发生的时间、报错的服务和具体的错误原因，读懂它，排查就完成了一大半。systemd 时代的 journalctl 正是为此而生的工具：它统一收集系统和服务的日志，支持按时间、按服务、按级别过滤，比翻 /var/log 下一堆零散文件高效得多。

先看最近发生了什么

最常用的起手式是看某个服务的最新日志：

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

-u 指定服务名，-n 100 只看最后 100 行，--no-pager 让输出直接打印而不是进入翻页器，方便复制和搜索。如果服务刚刚崩过，加上 -b 只看本次启动以来的日志，排除掉上次启动的旧记录干扰：

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

-p err 只显示错误及以上级别，噪音一下子少了很多。先看错误级别，再放宽到警告级别，是排查时省时间的顺序。

按时间圈定故障窗口

用户说“今天早上 9 点左右网站打不开”，日志排查就应该从时间入手，而不是从头翻到尾：

journalctl --since "2026-11-04 08:30" --until "2026-11-04 09:30" -p warning --no-pager

--since 和 --until 支持“yesterday”“-1 hour”这类相对写法，比如 --since "-1 hour" 就是最近一小时。把时间窗口收窄到故障前后半小时，往往几十行日志里就有答案。配合 -f 还能实时跟踪新日志，相当于给服务接上“心电图”：

journalctl -u myapp -f

服务重启后立刻跑这条命令，报错会一行行实时冒出来，复现问题时特别好用。

三个常见故障的日志读法

第一种是端口被占用。服务启动失败，日志里常出现“Address already in use”。这时用 ss -tlnp 查一下到底是谁占了端口，再决定是停掉旧进程还是改新服务的端口，不要反复重启同一个服务。

第二种是磁盘满了。日志里出现“No space left on device”时，先用 df -h 确认哪个分区满了，再用 du -sh /var/log/* 之类定位大文件。日志本身失控增长也是常见元凶，清理前先看清楚是哪个服务在刷屏，修好刷日志的根因比删文件更重要。

第三种是权限问题。日志里出现“Permission denied”时，先确认服务是以哪个用户运行的，再检查文件和目录的属主与权限。把权限改成 777 虽然能立刻“修好”，却是给服务器留了个大口子，正确做法是只给运行用户必要的读写权限。

养成排查习惯

排查时还有两点值得养成习惯。一是先看日志再动手改配置，改完配置重启服务后，立刻用 journalctl 确认新日志里没有新的报错，才算一次完整的修复。二是重要服务配上日志轮转和磁盘告警，避免日志把磁盘写满反过来拖垮服务——很多“半夜宕机”的根因，最后查下来都是磁盘被日志塞满了。

日志不会说谎，但它只对愿意读它的人有用。下次服务出问题，别急着重启，先花五分钟跑几条 journalctl，把故障时间、报错服务和错误信息圈出来，定位速度会快得多。