Linux 服务启动失败后的排查顺序：systemctl 和 journalctl 怎么看

Linux 服务启动失败时，很多人先去重启机器。这样做通常只会把现场清掉，真正有用的错误信息反而没了。使用 systemd 的系统，应该先看服务当前状态，再查本次启动对应的日志。

先看服务状态

以 nginx 为例：

sudo systemctl status nginx --no-pager

重点看三处：服务是不是 failed，最近一次退出的状态码是什么，以及日志末尾有没有明显的配置错误。状态页只展示当前或最近一次运行的信息，不能替代完整日志。

再查本次启动日志

sudo journalctl --unit=nginx -b --no-pager
sudo journalctl --unit=nginx -b -n 100 --no-pager

-b 表示当前这次启动，-n 100 只显示最后 100 行。这样比直接翻整个系统日志更容易定位问题。如果服务刚刚启动过，日志通常会直接告诉你是端口占用、配置文件语法错误，还是权限不足。

手动验证配置文件

如果日志指向配置问题，先用服务自身的检查命令，不要反复执行 restart：

sudo nginx -t
sudo systemctl restart nginx

对其他服务也一样，优先查它们提供的 configtest、check-config 或 validate 命令。配置检查通过后，再重启服务。否则每次 restart 都只是重复失败。

确认端口和文件权限

配置没有语法错误，也不代表服务能正常监听端口：

sudo ss -ltnp
sudo systemctl cat nginx
sudo namei -l /etc/nginx/nginx.conf

如果端口已经被其他进程占用，先确认那个进程能不能停。检查配置文件时，还要留意 systemd 服务实际加载的是哪个文件，以及运行用户是否有权限读取证书、日志目录和网站目录。

服务反复重启怎么办

先看失败计数和最近一段日志：

sudo systemctl show nginx -p ActiveState -p SubState -p NRestarts
sudo journalctl --unit=nginx --since "10 minutes ago" --no-pager

如果服务进入重启循环，不要马上把 RestartSec 调得很短。先处理导致进程退出的原因，否则只会让日志增长得更快。

保留排查现场

修复前可以把状态和日志保存下来：

sudo systemctl status nginx --no-pager > nginx-status.txt
sudo journalctl --unit=nginx -b --no-pager > nginx-journal.txt

这样即使后面重启了服务，也能回头比较修复前后的差异。systemd 的排查顺序可以概括为：状态、日志、配置检查、端口和权限。按这个顺序处理，比直接重启更容易找到根因。