Linux新手第一课：用journalctl读懂系统日志，而不是只会重启

很多新手遇到服务起不来，第一反应就是重启。重启有时能掩盖问题，却很少能解释问题。下一次同样的报错还会回来，而且你仍然不知道它为什么出现。学会看日志，才是把运维从碰运气变成可复现排查的第一步。

在现代Linux发行版里，systemd-journald会集中收集内核、服务和应用的日志，journalctl就是查它的工具。它比到处翻/var/log下的零散文件更省事，因为时间、服务名和优先级都已经结构化了。

先从最常用的三条命令开始。journalctl -xe会显示最近的日志并附带解释，适合刚出问题时快速扫一眼；journalctl -u nginx.service只看某一个服务的日志，排障时先把范围缩小到一个服务，能省掉大量无关信息；journalctl --since "2026-10-29 19:00"则按时间切分，只看故障发生前后的一段。

日志里最值得先看的不是每一行，而是级别和重复模式。err和crit往往指向真正失败的环节，warning则可能是前兆。同一条报错在短时间内反复出现，通常说明服务在不断重试，而不是偶发抖动。这时不要急着重启，先把第一次出现的时间点记下来，再往前找它依赖的服务有没有先挂掉。

一个常见的排查顺序是：先确认服务状态，再看日志，最后看配置。systemctl status可以告诉你服务是启动失败、被信号杀掉，还是根本没有运行；日志会告诉你它在启动的哪一步停下；配置则解释它为什么会在那一步停下。把这三者串起来，结论往往比单独看一行报错可靠得多。

还要提醒两点。第一，日志里可能包含路径、账号名甚至密钥片段，截图求助前先脱敏。第二，生产环境不要用journalctl -f长时间挂在前台刷屏，确认问题后就用时间范围和服务名把结果收敛到可读的规模。

下次服务再出问题，不妨先给自己五分钟：用journalctl定位服务、锁定时间、找到第一次报错，再决定是改配置、补依赖，还是真的需要重启。能说清楚问题是怎么发生的，比能把服务拉起来更重要。