systemctl 无“清除 failed 缓存”命令，因 failed 是实时状态而非缓存；每次 systemctl --failed 仅为当前快照扫描，状态修复后自动消失；需用 systemctl status 和 journalctl 排查根本原因，必要时用 systemctl reset-failed 重置标记。
systemctl 本身没有“清除 failed 状态计数缓存”的独立命令——failed 状态不是缓存，而是 systemd 实时检测并持久记录的服务运行结果。所谓“计数”只是 systemctl --failed 输出的当前快照，不存储历史计数，也不需要手动清空。
为什么不存在“清除 failed 缓存”这回事
systemd 将服务状态（active/failed/inactive）保存在运行时内存和 /run/systemd/ 中，重启后自动重置；失败记录本身不累积计数，每次 systemctl --failed 都是重新扫描当前所有 loaded 且状态为 failed 的单元。
- failed 是瞬时状态：服务启动失败 → systemd 标记为 failed；修复后 start 成功 → 状态自动变为 active，不再出现在 --failed 列表中
- 没有后台计数器或日志归档机制：systemd 不统计“这个服务失败过几次”，只关心“此刻是否 failed”
- journal 日志里有失败详情，但那是日志，不是缓存——删日志不会改变当前 failed 状态，只影响追溯能力
你真正需要的操作其实是这三步
如果看到 systemctl --failed 一直显示某服务 failed，说明问题没解决，不是“缓存没清”。应按顺序排查：
- 运行
systemctl status 服务名，重点看最后一行红字（如 “Failed to start …” 或 “exited with code 1”） - 查完整日志：
journalctl -u 服务名 --since "1 hour ago" --no-pager，找配置错误、路径缺失、用户不存在等根本原因 - 修复后必须执行
systemctl daemon-reload（改过 .service 文件时），再systemctl start 服务名—— 成功后它就自动从 --failed 列表消失
唯一接近“重置失败状态”的安全做法
仅当确认服务已修复、但状态仍卡在 failed（极少见，多因依赖未就绪或 systemd 内部短暂异常），可尝试：
-
systemctl reset-failed 服务名：清除该单元的 failed 标记，让 systemd 重新评估其状态（注意：不重启服务，也不修正错误） -
systemctl reset-failed（不带参数）：清除所有 failed 单元的标记 —— 但若服务实际仍无法启动，下次 start 会立刻再次 failed - ⚠️ 这不是“清缓存”，而是告诉 systemd：“请忽略上次失败记录，按当前配置重试”；它不能替代问题诊断
本质上，systemctl --failed 是个诊断仪表盘，不是故障数据库。盯着怎么“清”，不如直接看 status 和 journal 定位为什么失败。
