systemd 服务启动失败时，先记录单元状态、失败时间与对应日志，再决定是否重启。反复 restart 或先执行 reset-failed 可能改变当前状态和计数，却不能修复导致失败的程序、配置或依赖问题。

适用版本与前提

面向使用 systemd 管理系统服务的 Linux，示例按 systemd 239 及以上版本选取常用命令；发行版可能回移功能，应先查看本机版本和 man 手册。本文为 AI 辅助的 systemd 官方资料整理，未在目标机器实测。example.service 是占位单元名，必须替换为真实名称；默认仅查询，不执行停止、启动和重载。

systemctl --version
systemctl --failed --type=service --no-pager
systemctl status example.service --no-pager --full

一、先读加载状态和运行状态

Loaded 关注单元能否加载，Active 关注当前运行状态。not-found、masked 与 failed 需要不同处理；enabled 也不等于当前正在运行。status 面向人工阅读，只呈现当前或最近一次运行及有限日志，不能代替完整历史。定义见 systemctl 官方手册。

先确认名称、实例后缀和管理范围。例如用户会话服务需采用相应 --user 查询；不要把系统服务查不到直接理解成程序没有安装。记录退出原因和时间后再做变更，避免只截取最后一句通用失败提示。

二、按单元和时间窗口查看日志

journalctl -u example.service -b --since '-30 min' --no-pager
journalctl -u example.service -b -n 100 --no-pager

-u 选择单元，-b 限定本次启动，--since 选择最近 30 分钟，-n 100 选择最近 100 条；两条是不同视角，不需要一起拼成固定模板。先找失败前的首个具体错误，再读后续连锁信息。过滤与权限说明见 journalctl 官方手册。

没有输出时检查权限、时间范围、是否跨越重启以及应用是否另写日志。必要时由有权管理员查询；不为看日志而随意扩大账号权限。仅当需要查历史且日志仍保留时，去掉 -b 或选择对应启动记录。查询不到不证明故障从未发生。

三、核对实际单元文件与覆盖项

systemctl cat example.service

cat 展示磁盘上的单元及 drop-in 文件，用于核对启动命令、运行用户、目录和依赖；磁盘内容可能与管理器已加载的理解不同。不要把它当作“配置已生效”的证明，也不要未经核对直接复制到工单，文件可能包含敏感参数。

四、遇到启动限流，先修因再恢复

StartLimitIntervalSec 与 StartLimitBurst 控制一定时间内允许的启动次数，手动启动也可能计入。出现启动过频提示，应先追查此前为什么反复失败；限流机制见 systemd.unit 官方说明。

reset-failed 会清除失败状态及启动限流等计数，不是修复命令。仅在保存证据、修复根因且有变更安排后，才针对指定单元决定是否使用；不要省略单元名做全局清理，也不要直接关闭限流来掩盖故障。

验证与常见问题

完成经批准的修复后，重新查询相同单元及新时间窗口日志，并验证真实业务。对于长期运行服务，观察其是否稳定保持预期状态；一次启动成功不代表依赖和业务功能全部正常。

inactive 是否总是故障？不是。一次性任务完成后可能按设计退出，应结合单元类型、任务结果和日志判断，不要对所有 inactive 单元批量重启。Type=oneshot 与 RemainAfterExit 的关系见 systemd.service 官方说明。

最小记录包括主机与时间、单元名、版本、完整状态、故障前后日志和本次变更；分享前去除密码、令牌和内部地址。本文不提供伪造的成功输出。

相关阅读