用 journalctl 排查 Linux 服务启动失败

服务起不来时，很多人第一反应是反复 systemctl restart，却忘了先把原因看清楚。journalctl 是 systemd 自带的日志查看器，把启动失败的关键几行抓出来，往往比盲重试快得多。

先看这个服务自己的日志

假设服务名叫 nginx：

sudo journalctl -u nginx -n 50 --no-pager

-u 指定单元名，-n 50 只看最近 50 条，--no-pager 直接打到终端，方便复制。若刚重启过，可以加上时间窗口：

sudo journalctl -u nginx --since "10 min ago" --no-pager

输出里常见的坑包括：配置文件语法错误、端口被占用、权限不够、依赖的网络或挂载点还没就绪。

跟着实时日志一起看

有些问题只在启动瞬间出现，事后翻历史不够。可以一边重启一边盯：

# 终端 A
sudo journalctl -u nginx -f

# 终端 B
sudo systemctl restart nginx

-f 类似 tail -f，新日志会立刻刷出来。看到报错后按 Ctrl+C 停掉即可。

按优先级过滤，少被噪音淹没

只看错误和更严重的级别：

sudo journalctl -u nginx -p err..alert --since today --no-pager

-p 接受 emerg、alert、crit、err、warning、info、debug 等，也可以写成范围。排查启动失败时，先从 err 起通常就够了。

和 systemctl status 搭配

systemctl status nginx 会给出进程状态、最近几行日志和退出码，适合快速确认「是不是挂了」。真正要定位原因，还是回到 journalctl 看完整上下文。两个命令一起用，比只盯一个控制台窗口稳得多。

小习惯

1. 改完配置先 nginx -t（或对应服务的 config test），再 restart。
2. 失败时先记退出码和第一条 Failed / Error 行，再搜索文档或 Issue。
3. 长期跑在服务器上的服务，必要时把 Storage=persistent 配进 journald，避免重启后日志被清掉。

把「先读日志、再动手」养成习惯后，systemd 服务的启动问题大多能在几分钟内定位到具体配置或依赖，而不是在反复重启里空耗时间。