Linux 服务启动失败，先用 journalctl 缩小排查范围

Linux 服务启动失败时，终端里一句“启动失败”往往只是结果。立即反复重启，可能让关键错误淹没在重复输出里。更有效的起点是记录失败时间，再围绕同一次故障收集证据。下面以 nginx.service 为例，介绍一套从状态到日志的排查顺序；实际使用时请替换成机器上真实存在的服务名。

一、确认当前状态与服务名称

本文适用于由 systemd 管理系统服务的 Linux 环境，不适用于所有容器或精简系统。先执行：

systemctl status nginx.service --no-pager

重点看服务是否加载、当前是否失败，以及进程退出信息。如果显示找不到单元，先核对安装情况和名称。若名称都没有确认，后面的日志过滤也可能查错对象。状态页只适合快速概览，不应把其中几行输出当成全部日志。

二、把范围缩到一个服务

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

这里按服务过滤，并显示最近五十条记录。sudo 用于拥有相应授权时读取系统日志；普通账号可见的内容可能有限。阅读时从失败位置向前回看：最后一行常常说明启动失败，而前面的配置路径、权限错误或端口占用提示，才可能指向原因。不要只截取带有 failed 的一行。

三、围绕发生时间查询

如果故障出现在当天十点左右，可以按实际时间调整区间：

sudo journalctl -u nginx.service --since "09:55" --until "10:05" --no-pager

这样能减少无关历史记录。时间应按目标机器的时区理解，跨机器对照时尤其要确认时区。还可以追加 -b 限定本次启动，避免把以前启动留下的错误误判为当前问题。时间范围过窄也会遗漏线索，应保留故障前后几分钟。

四、观察一次操作产生的变化

sudo journalctl -u nginx.service -f

该命令持续显示新增记录，按 Ctrl+C 结束查看，不会因此停止被观察的服务。需要复现问题时，可在另一个终端执行已确认合适的操作，并记下操作时刻。观察重点是“这一步之后新增了什么”，而不是看到红色文字就立即修改配置。

五、没有输出也要继续核对

没有日志不等于服务正常。先检查服务名、读取权限和查询范围，再确认应用是否把详细错误写到了独立日志文件。准备寻求帮助时，保留时间、服务名、原始报错和最近的配置变更，分享前遮去令牌等敏感信息。

每次只验证一个假设，例如先核对报错指向的文件是否存在，再检查访问权限。修改后使用相同查询条件对比结果，并确认服务和实际功能均已恢复。把排查过程写成“现象、证据、假设、验证”四项记录，比堆积重启命令更容易复盘，也便于下次快速定位。