服务起不来先别急着重装：用 systemctl status 和 journalctl 把启动失败讲清楚

服务启动失败时，很多人第一反应是重装软件或者重启整台机器：重装一次不行就再重启一次，结果往往是服务偶尔能起来、过一会儿又倒下，真正的原因始终没有找到。服务起不来很少是“软件坏了”，多半是配置、权限、端口或依赖中的某一环没对上。先把失败的原因讲清楚，再动手修，顺序不能反。systemctl status 和 journalctl，就是干这件事最顺手的两个工具。

第一步是先用 systemctl status 看服务的当前状态，而不是直接重启。systemctl status 服务名会告诉你三件事：服务现在是 active、failed 还是 inactive；最近一次启动是什么时候；以及最后几行日志里有没有直接的报错。很多问题一看就明白：服务显示 failed，附带的报错是“配置文件第几行语法错误”；或者显示 inactive，是因为它根本没有被设置成开机自启，上次重启机器后就再也没起来过。没有这一步，重启只能算碰运气；有了这一步，问题就从“服务起不来”变成“某一个具体原因”。

第二步是用 journalctl 看完整的失败过程。systemctl status 只显示最后几行日志，真正的原因可能藏在更早的地方。用 journalctl -u 服务名 -n 100 看最近一百行，或者加上 --since “10 minutes ago” 只看最近十分钟的记录。常见情况有三种：一是端口被占用，日志里写着 address already in use，说明另一个进程已经占了这个端口，服务抢不到就退出了；二是权限不足，比如服务想写某个目录却没有写权限，日志里会出现 permission denied；三是依赖没起来，比如数据库还没就绪，应用连不上就直接退出了。先看日志再动手，修的方向才不会跑偏。

第三步是区分“配置错了”和“环境没准备好”。配置文件写错一个符号、少一个引号，服务往往一启动就退出，而且每次失败的报错都一模一样，这种属于配置问题，改配置、重新加载就能解决。环境问题则不一样：端口被别的进程占用、依赖的数据库还没启动、磁盘满了写不进日志，这些问题换一台机器、换一个时间可能就不复现。判断的方法很简单：先看日志里的报错是不是每次都相同，再看报错指向的是配置文件本身，还是配置文件之外的东西。前者改配置，后者先把环境恢复正常。

第四步是验证修复，而不是只看一次启动成功。改完配置后，先用 systemctl daemon-reload 重新加载配置（如果改的是 unit 文件，这一步不能省），再用 systemctl restart 重启服务，然后马上用 systemctl status 确认它处于 active，并且用 journalctl 看新日志里没有新的报错。更稳妥的做法是多等一会儿，或者模拟一次真实请求，看服务是不是真的在正常工作。只看“启动命令没有报错”是不够的，有些服务启动时不报错，但第一次处理请求时才暴露问题。

最后养成三个习惯：一是改配置之前先备份原文件，改坏了能立刻恢复；二是每次排查都先看 status 和 journalctl，养成“先读日志、再改东西”的顺序；三是重要的服务都设置成开机自启，并且定期看一眼有没有 failed 的服务。服务启动失败很少是孤立的软件故障，它背后往往是配置、端口、权限或依赖中的某一环。先看状态、再读日志、最后才动手修，服务起不来的排查才不会越重装越乱。