Linux 服务启动失败怎么定位：journalctl、状态码与回滚配置

凌晨发布后，Nginx 还在监听 443，旁边的业务 worker 却突然变成了 failed。这类故障先别急着重启整台机器：systemd 已经把失败原因、退出状态和本次启动的日志留在对应 unit 里。按“状态确认 → 本次日志 → 配置校验 → 小范围回滚”的顺序，通常几分钟就能分清是参数写错、权限不足，还是依赖服务没准备好。

systemd 启动失败时，先确认失败的是哪个 unit

假设服务名是 report-worker.service。第一条命令不要带一长串过滤条件，先把 unit 当前状态、最近一次退出状态和 systemd 给出的短错误读出来：

sudo systemctl status report-worker.service --no-pager -l
sudo systemctl is-enabled report-worker.service
sudo systemctl is-active report-worker.service

inactive 表示当前没运行，failed 才说明最近一次启动失败。is-enabled 只回答开机是否启用，不能代替运行状态判断。这里的结果先别下结论，status 里的最后一行往往只是“进程退出”，真正的文件路径或参数错误要到日志里找。

journalctl 怎么只看本次启动留下的关键证据

先看该 unit 最近一轮日志，保留完整行，避免错误被终端截断：

sudo journalctl -u report-worker.service -b --since "10 minutes ago" --no-pager -o short-precise

-u 限定服务，-b 限定当前系统启动，--since 再缩小到发布操作附近。若服务被反复拉起，可以补上：

sudo journalctl -u report-worker.service -b -n 80 --no-pager
sudo journalctl -fu report-worker.service

第一条用于回看最近 80 行，第二条用于在另一个终端重新启动服务时实时观察。你要找的是“第一个具体失败点”，例如 Failed to open /etc/report-worker/config.yaml: Permission denied，而不是后面重复出现的 Start request repeated too quickly。

退出状态码只能缩小范围，不能单独当作根因

常见状态码可以帮助你决定下一步，但不要把数字直接翻译成最终结论：

例如看到 203/EXEC，先执行 systemctl cat report-worker.service，确认 ExecStart 的文件确实存在，再用服务用户做一次只读检查：

sudo systemctl cat report-worker.service
sudo -u report-worker -- test -x /opt/report-worker/bin/worker
echo $?

最后输出为 0 只能说明该用户能执行文件；如果 unit 里还有工作目录、环境文件或端口权限，仍需结合 journal 继续核对。

修改 drop-in 配置后，如何验证并保留回滚路径

不要直接编辑发行版提供的主 unit 文件。用 sudo systemctl edit report-worker.service 创建 drop-in，把本次变更限制在一个可撤销文件里。比如只修正环境文件路径：

[Service]
EnvironmentFile=/etc/report-worker/worker.env

保存后按这个顺序执行：

sudo systemctl daemon-reload
sudo systemctl reset-failed report-worker.service
sudo systemctl restart report-worker.service
sudo systemctl status report-worker.service --no-pager -l
sudo journalctl -u report-worker.service -b -n 40 --no-pager

如果状态变成 active (running)，日志里出现应用自己的 ready 信息，且端口检查通过，才算修复闭环。若新配置让服务更糟，执行 sudo systemctl revert report-worker.service 删除由 systemctl edit 产生的本地覆盖，再次 daemon-reload 并重启；手工写入的自定义 drop-in 则先记录路径，再有选择地移走。

三个容易把排查带偏的做法

只看 status 的一行红字

status 是入口，不是完整诊断报告。尤其是应用返回 1 时，必须回到同一 unit 的 journal，查看它读取了哪个文件、以哪个用户运行。

修改 unit 后忘记 daemon-reload

systemd 可能仍在使用旧的 unit 定义。修改 drop-in 后先 reload，再 restart；不要用“多重启几次”替代重新加载配置。

看到 repeated too quickly 就继续重启

这只是 systemd 的启动限流提示。先找更早的第一条具体错误，修好根因后再启动，避免把日志刷成一串相同的失败记录。

延伸问答：日志、依赖和开机启动

journalctl 看不到服务日志怎么办？

先确认 unit 名称和权限，再检查服务是否真的由 systemd 管理；使用 journalctl -u 时不要误把进程名当 unit 名称。

服务能手工运行，为什么 systemd 仍然失败？

两者的用户、工作目录、环境变量和标准输入可能不同。对照 systemctl cat 中的 User、WorkingDirectory、EnvironmentFile 和 ExecStart。

修复后需要重新 enable 吗？

只改启动参数通常不需要；只有开机启用状态变化时才执行 systemctl enable。用 is-enabled 单独核对，别把 enable 和 restart 混为一件事。

把一次失败收敛成可复用的检查顺序

稳定的顺序是：先用 status 确认 unit，再用带 -b 和时间范围的 journalctl 找第一条具体错误，接着用 systemctl cat 对照实际配置，最后在 drop-in 中做最小修改并用 active 状态和应用 ready 日志复核。数字状态码适合导航，不适合替代证据；保留回滚路径，下一次发布才不会把一次小配置错误扩大成整机操作。