Linux 服务为什么启动后立刻退出：启动命令、Type 与状态码排查

一台 Linux 机器上的 report-worker.service 每次启动都只留下几行日志，随后状态变成 failed。这时别急着把重启策略改成“永远重启”：进程可能是配置检查失败后主动退出，也可能是 unit 的 Type 与程序行为不匹配。把启动命令、服务类型和退出状态码对齐，通常比盲目重启更快找到根因。

先把“立刻退出”拆成三个可验证问题

“服务启动后没了”只是现象，不是结论。第一轮检查要回答三个问题：主进程有没有真正被拉起，程序以什么状态结束，服务管理器把这次结束归类成了什么结果。

systemctl status report-worker.service --no-pager -l
systemctl show report-worker.service \
  -p ActiveState -p SubState -p Result \
  -p ExecMainCode -p ExecMainStatus -p MainPID
journalctl -u report-worker.service -b --no-pager -n 80

如果 ExecMainCode=exited 且 ExecMainStatus 是非零值，说明程序启动后主动返回了失败状态；如果结果是 signal，要继续看是否被信号终止；如果 MainPID=0，则不能据此断言程序从未启动过，短命进程可能已经退出。

旧的 unit 写法为什么容易误判启动完成

很多 unit 文件只写了一个启动命令，然后把“命令被调用”理解成“业务已经就绪”。但 systemd 的服务类型定义了它何时认为启动阶段结束。对常驻前台进程，Type=simple 通常够用；程序需要显式报告就绪时，才考虑 Type=notify；一次性初始化任务则更适合 Type=oneshot。

如果一个只执行配置迁移的程序被写成常驻服务，命令成功返回后 unit 可能很快结束；反过来，一个需要持续占用前台的 worker 如果自己转入后台，服务管理器也可能无法正确跟踪它。

从启动命令和退出码定位真正根因

接下来核对 unit 的最终内容，而不是只看某个片段文件。覆盖配置、环境文件和工作目录往往藏在 drop-in 中。

systemctl cat report-worker.service
systemctl show report-worker.service \
  -p FragmentPath -p DropInPaths -p WorkingDirectory \
  -p User -p EnvironmentFiles -p ExecStart

假设日志出现 config validation failed，状态码为 2，优先检查 WorkingDirectory、环境文件路径和运行用户是否能读取配置。不要先把 Restart=on-failure 改成 always；那只会让同一个参数错误更快进入启动频率限制。

[Service]
Type=simple
User=report
WorkingDirectory=/srv/report-worker
ExecStart=/srv/report-worker/bin/worker --config /etc/report-worker/config.toml
Restart=on-failure
RestartSec=5

手工验证时要尽量复现 unit 的用户、目录和环境。若程序支持配置检查子命令，可以先用同一配置文件做只读检查；若不支持，至少确认文件权限、端口占用和依赖地址，再观察同一条启动命令能否保持前台运行。

修复后怎样证明 unit 真的稳定

修改 unit 或 drop-in 后，先让 systemd 重新读取配置，再重启一次并观察连续运行状态。

sudo systemctl daemon-reload
sudo systemctl restart report-worker.service
systemctl show report-worker.service -p ActiveState -p SubState -p MainPID -p Result
sleep 3
systemctl is-active report-worker.service
journalctl -u report-worker.service -b --no-pager -n 40

合格结果不是“命令返回成功”这么简单：is-active 应持续返回 active，MainPID 应指向仍存在的前台进程，journal 中不再出现同一启动失败，且业务自己的健康检查也能通过。若程序本来就是一次性任务，则应按 oneshot 的成功返回和产物验收，不要强行要求它长期 active。

几个容易把现场越修越乱的动作

• 反复执行 restart：会冲掉第一次失败和后续失败的时间关系，先保留 journal 现场。
• 只看 systemctl status 的最后一屏：长命令可能被截断，要用 -l 和 journal 对照。
• 直接扩大权限：配置读不到时先查运行用户、父目录执行位和文件属主，不要先改成 root。
• 把所有退出都当成异常：迁移、清理、生成配置等一次性任务成功返回后本来就会结束。

相关问题

为什么服务是 active 但业务端口还没通？

Type=simple 只说明启动阶段已交给进程，不能替代端口监听和业务健康检查。需要把应用就绪探针或外部检查纳入验收。

Result=exit-code 和状态码 1 说明什么？

它说明主进程以非零状态返回，具体原因仍要结合启动日志、配置文件和运行用户判断，状态码本身不是错误描述。

修改 service 文件后为什么没生效？

先执行 daemon-reload，再重启服务；同时用 systemctl cat 查看最终合并后的 unit，确认 drop-in 没有覆盖你的修改。

把排查结论留成一张验收清单

以后再遇到“启动后立刻退出”，按“最终配置—启动命令—退出状态—日志首错—修复后持续运行”的顺序走一遍。只要每一层都有可复查证据，就能区分程序本身失败、服务类型选择不当和管理器限流，不必靠反复重启碰运气。