服务起不来别急着重启：用 journalctl 先把报错找出来

服务起不来的时候，最耗时间的往往不是修，而是找。很多人第一反应是 systemctl restart，再看一眼状态，发现还是 failed，于是又重启一遍。其实重启之前，先花两分钟把报错找出来，后面的路会顺很多。

一、先看状态，再看日志

systemctl status 先给一个结论：服务现在是 active、failed，还是根本没跑起来。它还会带上最近几行日志和退出码，能帮你判断问题出在启动阶段，还是运行一段时间后才挂掉。但 status 只是一个摘要，真正的原因通常藏在日志里。

这时候再用 journalctl。最常用的是下面这一组：

journalctl -u 服务名 -e
journalctl -u 服务名 --since “10 minutes ago”
journalctl -u 服务名 -p err --since today

第一条跳到日志末尾，第二条只看最近十分钟，第三条只看错误级别。服务名要写完整，比如 nginx.service，不要只写 nginx，否则可能对不上。

二、日志里先找这几类信息

端口被占用是最常见的一种。日志里出现 Address already in use，基本就是端口已经被别的进程占了。用 ss -tlnp 看看是哪个进程，再决定是停掉旧进程，还是改端口，而不是反复重启同一个服务。

配置文件写错了也常见。少个括号、路径写错、变量没定义，服务往往在启动第一步就退出。日志里如果出现 failed to load、No such file、permission denied 这类词，顺着它给出的文件和行号去改，比凭感觉改配置快得多。

还有一类是依赖没起来。服务本身没问题，但它依赖的数据库、挂载目录、网络还没就绪，启动就失败。这种情况下日志里的时间点很关键：看它是在什么时候退出的，前面有没有 waiting、timeout、connection refused。

三、一个顺手的排查顺序

我自己常用的顺序是固定的：先 status 确认状态，再 journalctl -u 看最近的报错，接着按报错里的关键词定位到配置文件或端口，最后改一处、重启一次、再看一次日志。改完不要连续重启三次，日志会被刷过去，反而不容易确认这次改动到底有没有起作用。

另外注意两个小坑。第一，系统时间如果不对，–since 很容易查错时间段，先确认 date 的输出再限定时间。第二，日志可能已经轮转，太久以前的报错不一定还在当前日志里，查不到时可以把时间范围放宽，或者看看服务自己的日志文件。

服务起不来并不可怕，可怕的是在没有报错的情况下乱改。先让 journalctl 把话说清楚，再动手，多数问题其实在第一屏日志里就已经写明了。