用 journalctl 快速定位服务启动失败

服务起不来，先别急着重装，更别急着重启整台机器。systemd 会把服务的标准输出、标准错误和退出信息都记进 journal，journalctl 就是顺着这条线找原因最快的工具。

一、先看最近的日志

journalctl -u nginx.service --since “10 minutes ago”

只看最近 10 分钟，避免被旧日志淹没。也可以看最后 100 行：

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

–no-pager 可以防止进入 less 分页，适合在排障时直接输出。

二、按优先级过滤

journalctl -u myapp.service -p err --since today

只看 err 及以上级别。先看错误再看警告：很多启动失败的根因，就藏在 “Failed to start” 上面几行，比如端口被占用、配置文件语法错误、依赖文件不存在。

三、看完整的失败过程

journalctl -u myapp.service -b

只看本次启动以来的日志，排除上一次启动的干扰。再配合 systemctl status 看退出码：退出码 1 常是程序自身报错，203 常是 ExecStart 路径或权限问题，127 常是命令找不到。

四、一个实战例子

某次 nginx 启动失败，systemctl status 只显示 failed。用 journalctl -u nginx -n 50 查到 “bind() to 0.0.0.0:80 failed (98: Address already in use)”，再用 ss -tlnp | grep :80 找到占用 80 端口的旧进程，结束它之后服务一次启动成功。没有 journalctl，这一步只能靠猜。

五、两个容易踩的坑

第一，日志可能被轮转或清理。journald 默认按磁盘配额保留日志，查不到旧日志时，先看 /var/log/messages 或应用自己的日志文件。

第二，时间可能不对。服务器时区或时钟不同步，会让 --since 框错时间段，查之前先用 date 和 timedatectl 确认时间。

结语：服务启动失败，先执行 journalctl -u 服务名 -p err --since today，再结合 systemctl status 看退出码，大多数问题五分钟内就能定位到具体原因。