journalctl 查服务启动失败：从一条报错定位 systemd 服务挂掉的原因

凌晨三点，监控告警响了：服务器上的 Web 服务起不来了。执行 systemctl status nginx.service，只看到一行 Active: failed，没有任何原因。这时候别急着反复重启，先让 journalctl 把 systemd 的日志翻出来，报错的源头往往就藏在最后几行里。

一、-u：只看这一个服务

systemctl status 只能看到最近十几行日志。想看完整经过，用 journalctl 按服务过滤：

journalctl -u nginx.service

只输出 nginx 这个单元的日志，不会被其他服务的记录淹没。

二、-xe：从末尾开始看

journalctl -xe

-x 会附加一段解释，-e 直接跳到日志末尾，也就是故障刚发生的位置。服务刚挂掉时最省事。

三、--since：把时间窗口圈出来

知道故障大概发生在几点，就用 --since 和 --until 圈定范围：

journalctl -u nginx.service --since "03:00" --until "04:00"

也可以写相对时间，或用 -b 只看本次开机后的日志。

四、-f：复现时实时跟踪

如果故障能复现，一边 systemctl restart，一边在另一个终端跑 journalctl -u nginx.service -f，日志会实时滚动，启动瞬间的报错会原样出现。

五、一个真实的排查过程

前段时间遇到一次 nginx 启动失败，journalctl -u nginx.service --since "10 minutes ago" 里看到关键一行：

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

80 端口被占了。ss -tlnp | grep :80 查到一个上次异常退出后没释放的旧进程，kill 掉再启动就恢复了。另一次是配置里 server 写错了一个字母，nginx -t 能提前发现。

总结

systemctl status 只能告诉你服务挂了，journalctl 才能告诉你为什么挂。记住四组用法：-u 按服务过滤，-xe 从末尾看并附解释，--since 圈定时间，-f 实时跟踪。再配合端口、配置这两处检查，大多数启动失败都能在几分钟内定位原因，而不是靠反复重启碰运气。