failed 状态是什么
服务启动或运行中报错退出，systemd 会把该单元标记为 failed，并在有限次重启（默认 5 次 / 10 秒窗口）后停止继续重启，进入 start-limit-hit 状态。failed 单元会留在内存里的失败列表中，systemctl --failed 能一次列全，reset-failed 则清掉失败标记与重启计数。理解这层机制的关键在于：标记只是现象，根因在程序自己的日志里，复位不等于修复。
基本信息
| 列出失败单元 | systemctl --failed |
|---|---|
| 复位标记 | systemctl reset-failed [单元名] |
| 定位手段 | status 摘要 + journalctl -u 单元详细日志 |
| 默认重启限速 | 10 秒内最多 5 次，超出后不再拉起 |
| 适用平台 | Kylin V10 / UOS 服务器版 / openEuler |
典型使用场景
- 开机后巡检：一条命令列出所有没起来的服务，代替逐个点检
- 改完配置验证：修好根因后 reset-failed 再启动，观察是否复发
- 清理干扰信息：把已知的、不打算启用的失败单元复位，让 --failed 回到干净基线
- 判断是否被限速：状态里出现 start-limit-hit 说明已经放弃重启，必须先修根因
- 排查依赖拖累：失败原因写着 dependency failed 时，要顺着依赖链找真正的源头
- 上线前验收：确认没有遗留失败单元，避免带病交付
排查流程
排查流程
systemctl --failed # 先看有几个失败单元
systemctl status myapp.service -l --no-pager # 摘要，含退出码与最近日志
journalctl -u myapp.service -n 100 --no-pager # 程序自己打印的报错
systemctl cat myapp.service # 确认最终生效的单元定义
systemctl reset-failed myapp.service # 修完根因后清掉失败标记
systemctl start myapp.service # 重新启动并持续观察
systemctl --failed # 复查是否还有遗留失败信息读取要点
| 信息 | 含义 | 处理方向 |
|---|---|---|
| code=exited, status=1 | 程序自己返回错误码退出 | 看日志中程序输出的报错 |
| code=exited, status=203 | 启动时无法执行指定文件 | 核对路径、权限与解释器 |
| code=exited, status=226 | 涉及命名空间或路径不可访问 | 检查工作目录与相关挂载点 |
| start-limit-hit | 反复失败触发限速，已停止拉起 | 先修根因，再 reset-failed 后启动 |
| dependency failed | 依赖的单元没起来 | 沿依赖链找到最初的失败单元 |
reset-failed 只清理失败标记和重启计数，不修复任何问题。清完立刻 start 才能验证；如果错误相同，说明根因没变，应回到日志继续分析。
有些单元失败与自身无关：被 After、Wants、Requires 关联的单元没起来时会连带失败。此时不该去改这个单元，而应顺着提示找链路上第一个出错的单元，往往一次修复能解决一串失败。