RUNBOOK / systemd
systemctl reset-failed：先修复根因再清除失败状态
systemctl status 显示 unit 仍处于 failed，修复配置后需要区分服务是否已恢复与 failed 状态是否已重置。
故障现象与判断依据
最可能原因
systemctl 官方手册说明 reset-failed 只会重置指定 unit 的 failed 状态；它不能修复退出码、配置、权限或依赖问题，因此必须在诊断和成功启动之后使用。
LOG● app.service - Application
Active: failed (Result: exit-code)
$ systemctl is-failed app.service
failed安全诊断
以下命令用于读取状态、验证解析或复现请求；先确认目标主机、权限与影响范围。命令中的占位符必须替换为当前环境的实际值。
READ / VERIFYsystemctl status <unit> --no-pager
journalctl -u <unit> -b --no-pager
systemctl start <unit>
systemctl is-active <unit>
# 仅在已经恢复后执行：
systemctl reset-failed <unit>推荐修复步骤
- 1先执行 systemctl status <unit> --no-pager 与 journalctl -u <unit> -b --no-pager，确认导致失败的实际事件已处理。
- 2执行 systemctl start <unit> 并用 systemctl is-active <unit> 验证服务已是 active；如果仍失败，返回日志继续定位。
- 3只对确认已恢复的目标 unit 执行 systemctl reset-failed <unit>，不要对所有 unit 批量重置以掩盖告警历史。
验证、限制与回滚
修复后的验证
systemctl is-active <unit> 返回 active，systemctl is-failed <unit> 返回 inactive 或没有失败状态，且新日志没有同类退出错误。
风险提示与回滚
不要以关闭证书校验、删除全部缓存、无限重试、关闭防火墙或放宽到 chmod 777 来替代根因定位。任何配置变更前先保留原文件和校验结果；若验证失败，恢复该备份并重新采集日志。
可信来源与适用边界
参考来源systemctl | systemd ↗
reset-failed resets the failed state of specified units 此页将环境级案例与本 Runbook 的检查步骤分开呈现，不能把示例日志当作当前服务器的真实事件。