巡检失败单元
系统启动后先跑一条命令列出所有进入失败状态的单元，是登录机器后的标准体检动作。它把「有没有东西在报错」压缩成几行输出，再用清理命令复位历史失败状态。要注意两者分工不同：一个是发现问题，一个是清理状态，清理从来不等于修复。
基本信息
| 适用场景 | 例行巡检与开机后的快速体检 |
|---|---|
| 命令语法 | 列出失败单元；对指定单元清理失败状态 |
| 相关设置 | 单元的启动频率限制与失败计数 |
| 与排障的关系 | 清理状态不能替代查原因 |
典型使用场景
- 登录后例行体检：一眼看清有没有服务处于失败状态
- 修复后清理计数：解除启动频率限制，便于重新拉起
- 一次性复位：清空全部失败状态，重新观察
- 监控对接：脚本定期采集失败单元数量
- 验证修复效果：重启服务后确认不再进入失败状态
常用示例
常用示例
systemctl --failed # 列出失败单元
systemctl status myapp # 看具体失败原因
systemctl reset-failed myapp # 清失败计数，解除启动频率限制
systemctl --failed --no-legend --plain # 输出更规整，便于脚本处理
systemctl reset-failed # 复位全部失败状态命令分工
| 命令 | 作用 | 注意 |
|---|---|---|
| 列出失败单元 | 发现处于失败状态的单元 | 巡检入口 |
| 查看单元状态 | 看失败原因与最近日志 | 定位故障原因 |
| 清失败计数 | 解除启动频率限制 | 修好之后再做 |
| 复位全部失败 | 一次性清空失败状态 | 会丢掉失败计数信息 |
| 采集失败数量 | 接入监控与告警 | 建议纳入例行巡检 |
清理失败状态只改状态、不解决问题。不查明原因，下次触发还会失败，而且计数被清掉后，「反复失败」这个信号也随之消失。
触发启动频率限制的服务在清理计数之前会拒绝再次启动。修好问题后先清理再启动，这个顺序不能颠倒。