mirror of
https://gitcode.com/JianFeeeee/HomeAgent.git
synced 2026-11-01 06:47:29 +00:00
198811253a
## 需求
WebUI 加关机与重启按钮，内核提供对应内部接口。有些状态变更只能靠重启
生效（换 LLM 源、换主密钥），没有这条通道时用户只能 ssh 上去敲 systemctl。
## 设计：复用心跳，不新开通道（用户指出的方向）
guard 与 worker 之间已经有一条现成的、每 5s 一次的单向通报（心跳文件，
内容原本是 `t=<unix>`，只用来刷 mtime）。用户点按钮本质就是"我要你在
下一次心跳时知道这件事"——再开 unix socket / 信号 / 临时文件，只会多出
一套要防重、防丢、防竞态的机制。
WebUI 点按钮
→ POST /api/v1/kernel/{restart,shutdown}
→ sdk.KernelControlAPI（只投递，立即返回）
→ 下一次心跳把 `cmd=restart|shutdown reason=...` 写进 <data>/heartbeat
→ 重启：worker 清理 → exit 42 → guard 重拉（**既有机制，零改动**）
关机：guard 在 workerCleanExit 分支读到 cmd=shutdown
→ systemctl stop → 不再拉起
★ 关机为什么必须由 guard 做：
unit 是 Restart=always，guard 自己 return 会被 systemd 立刻拉起
（用户点了"关机"、几秒后服务又活了）。必须显式 systemctl stop。
而不让 worker 自己停：它是被守护方，且**只有 guard 知道这次该不该重拉**。
★ 指令必须一次性消费：guard 读完立即原子重写文件清除 cmd 行，
否则每次心跳都读到同一条 ⇒ 无限重启/关机。worker 侧还要检查
"指令写过但文件里没了" ⇒ 已被消费 ⇒ 清本地 pending，否则又写回去。
## 顺带修的真缺陷：心跳文件无限增长
生产实测 **14.6MB**（纯 O_APPEND，约 70 天）。心跳的唯一职责是刷 mtime，
历史行没有任何读者 ⇒ 每次 consume 要整读 14.6MB（实测 27ms）。
改为 O_TRUNC 滚动写：只保留当前一行。真机验证 15,322,164 → 13 字节。
consume 也加了尺寸守卫（大文件只读尾部 8KB）。
## 安全：能力分级 + 白名单（两道）
1. proc 桥的 method 能力表：新增 `CapKernelControl` 一档。
★ 判据 `TestCapability_AllMethodsClassified` 当场报出
"未登记 ⇒ 会按 CapCore 放行，绕过权限检查" —— 那意味着任何插件都能关机。
2. 内置插件走 `SDKConfig.KernelControl`，第一版我写成"有就发"，
等于全部内置插件都能关机。改为按名字白名单（目前只有 webui）。
## 判据（7 条）
心跳：解析 / 消费后必须清除 / worker 不得写回已消费指令 / 未消费时必须续写
能力：只有白名单插件拿得到 / 未装配时返回 nil 不 panic / SDK nil 安全
心跳文件：不得无限增长 / 大文件只读尾部且读后收敛
变异 6/6 咬住。全量 53 包 ok。
## UI
导航底栏两个图标按钮（与主题/语言/退出并列）：重启有确认框 + 轮询等它
回来并自动刷新；关机有**二次确认且写清后果**（必须人工 systemctl start）。
两者都先把响应写回浏览器并 Flush，再让内核退出 —— 否则用户看到的是
connection reset，无法区分"正在重启"和"真出故障了"。
37 lines
1.7 KiB
Go
37 lines
1.7 KiB
Go
package sdk
|
||
|
||
// KernelControlAPI：插件请求**内核本身**重启或关机。
|
||
//
|
||
// ## 为什么需要它
|
||
//
|
||
// 有些状态变更只能靠重启内核生效（典型：改了 LLM 源、换了主密钥、
|
||
// 升级了要重新装配的配置）。没有这条通道时，用户只能自己去 ssh 上敲
|
||
// systemctl —— 而 WebUI 是大多数人唯一会用的界面。
|
||
//
|
||
// ## 语义边界（重要，别指望它做更多）
|
||
//
|
||
// 这两个方法都是**异步**的：它们只把请求投递给内核，立刻返回。
|
||
// 调用方（WebUI）应当先给用户一个明确回应（"正在重启，页面稍后自动重连"），
|
||
// 而不是等待返回 —— 内核真的会在这几秒内消失。
|
||
//
|
||
// 进程会怎么走：
|
||
//
|
||
// RequestKernelRestart ⇒ 内核清理（停插件、flush、CloseAll）→ exit 42
|
||
// → guard 用**当前二进制**重拉，不经过 systemd、
|
||
// 不计失败轮次（这就是"热更新"那条路）
|
||
// RequestKernelShutdown ⇒ 内核清理 → 通知 guard 主动停机 → systemd 不再拉起
|
||
//
|
||
// ★ 关机为什么不能用"guard 退出"实现：systemd 是 Restart=always，
|
||
// guard 退出会被它无条件重新拉起。必须显式 `systemctl stop`）
|
||
//
|
||
// ## 失败语义
|
||
//
|
||
// 返回错误只表示**请求没被接受**（例如内核未装配控制通道、或该功能被禁用），
|
||
// 不表示"没重启成功"——成功投递后本进程就会退出，返回值本身没有后续。
|
||
type KernelControlAPI interface {
|
||
// RequestKernelRestart 请求重启内核（热重启，guard 重拉）。
|
||
RequestKernelRestart(reason string) error
|
||
// RequestKernelShutdown 请求关闭内核（systemd 不再拉起）。
|
||
RequestKernelShutdown(reason string) error
|
||
}
|