（14687期）restart-guard – Gateway 安全重启与智能守护

Gateway 安全重启与智能守护 OpenClaw 官方运维工具，安全重启 Gateway 并自动验证恢复状态，保障服务连续性。 使用说明 核心用法 Restart Guard 是专为 OpenClaw Gateway 设计的安全重启工具，采用多阶段流水线确保重启过程可控可恢复。完整流程包含四个环节：首先通过 write_context.py 生成带 YAML frontmatter 的上下文文件，记录重启原因、验证命令和恢复步骤；随后 restart.py 执行预检查、配置备份、派生守护进程并触发重启；守护进程 guardian.py 在 Gateway 重启后独立运行，轮询健康状态；最后 postcheck.py 执行验证命令并输出结果报告。整个设计强调"状态可恢复、失败可感知、操作可审计"。 显著优点 该 Skill 的工程成熟度较高：仅依赖 Python 标准库，彻底规避供应链攻击风险；守护进程采用 startnewsession=True 实现真正的进程组隔离，确保监控不随父进程终止；内置 600 秒冷却锁和连续失败上限，有效防止重启风暴；多通道通知机制（OpenClaw 原生消息优先，Telegram/Discord/Slack/Webhook 兜底）保证异常必达；配置自动备份与回滚路径预留，为故障恢复提供安全边际。 潜在缺点与局限性 命令注入风险是最大隐患：：guardian.py 和 postcheck.py 中多处使用 shell=True 执行配置/上下文中的命令，若配置文件被篡改可导致任意代码执行。此外，通知模块将 Bearer Token 暴露在 curl 命令行参数中，可能被进程监控工具捕获；Webhook URL 缺乏 SSRF 防护，存在内网探测风险。功能层面，该 Skill 强绑定 OpenClaw 生态，无法迁移至其他 Gateway 平台；验证命令的"预期输出"匹配采用简单字符串比较，复杂场景下可能误判。 适合的目标群体 主要面向 OpenClaw 平台运维人员、SRE 工程师及需要频繁调整 Gateway 配置的开发团队。特别适合以下场景：模型切换后的热重启、插件更新后的服务刷新、配置变更后的生效验证，以及对服务可用性有明确 SLA 要求的生产环境。 使用风险 除前述安全漏洞外，常规风险包括：守护进程派生失败可能导致重启状态无人监控；多通知通道同时配置时可能产生消息轰炸；健康检查命令若配置不当（如超时过短）会引发误报；锁文件 /tmp/restart-guard.lock 若因异常退出未清理，需手动介入。建议在非关键环境充分验证验证命令的可靠性后再投入生产。 原始说明 Deterministic OpenClaw gateway restart with down/up state-machine verification, origin-session proactive ACK, and backward-compatible config.