fix(chv-muse-r12fix3-1): worker 开机时序竞态:Condition + path 触发,不赌重启预算(P6 缺口 ①)

R12 复测 2 钉死:剩下的 226 只点名 /home/chv/workspace——工作区由
cloud-final 的 chv-sync boot 克隆出来,晚于 multi-user.target 约
9 秒,worker 的 5 次启动预算在工作区出现前耗尽(5 台 VM 2 台
failed,手工 reset-failed + start 后立即 active,二进制无辜)。

修法三选一,选 (a)——让服务根本不在工作区出现前启动:
新单元 chv-gitea-worker.path(PathExists=/home/chv/workspace,
工作区一出现即触发启动)+ 服务加
ConditionPathExists=/home/chv/workspace(开机那次启动在命名空间
搭建之前干净跳过,不 226、不耗重启预算)。两者缺一不可:
Condition 本身绝不重试,没有 .path 它就是一次跳过、服务永远不
起;只有 .path 而无 Condition,开机那次启动仍会在命名空间搭建
时 226 撞上限速。WantedBy=multi-user.target 保留(is-enabled 仍
为 enabled),runcmd 只启动 .path 单元(cloud-final 时工作区尚
未 clone,直接 start 服务会 226);.path 进 buildinfo contents
与两处 lockfile 登记,P6 预检由三件扩为四件。

不用 (b) 放宽 StartLimit:放宽只是把竞态窗口拉大,wake 时间在
负载下已翻倍(R12 复测 2),预算仍可能耗尽,仍是时序赌博。
不用 (c) 把工作区创建提前到 tmpfiles-setup 之前:/home/chv 本身
07:23:40 才出现(cloud-init 建 chv 用户),晚于 tmpfiles-setup
(07:23:24);硬约束:绝不盲目补 tmpfiles 行。ExecStartPre 也不
行——命名空间搭建在它之前,救不了 226。

测试:WorkerUnitBootRaceTest 新增 8 项——Condition 在位、
StartLimit 未放宽(修法语义钉)、.path 触发配对(PathExists +
WantedBy、无 Unit= 覆盖)、服务 WantedBy 保留、build.sh 启用
.path + runcmd 只起 .path、绝无工作区 tmpfiles 行、buildinfo 与
lockfile 登记;BuildInfoContentsTest 的 P6 件加 .path;P2/P4 干
跑夹具一并拷入 .path。P6/P2/P4 三模块 174 项全过。
This commit is contained in:
host committed 2026-11-08 09:45:48 +00:00
1 parent 7c517f7fcc
commit e31354dc58
10 files changed
+165 -15

No files matched your search

+10 -2
View File
@@ -58,7 +58,13 @@ P3(authd/sentinel 本体——只读、不重写、不改接口)、不碰 P4
单元外;`ProtectSystem=strict`、`PrivateTmp`、`NoNewPrivileges`、
`CapabilityBoundingSet=` 空、`RestrictAddressFamilies=AF_UNIX AF_INET
AF_INET6`、`SystemCallFilter=@system-service`、读写路径只限
`/home/chv/workspace` 与 `/run/chv-gitea`)。
`/home/chv/workspace` 与 `/run/chv-gitea`)。round-12 修复轮第三轮
(缺口 ①):加 `ConditionPathExists=/home/chv/workspace`(开机那次
启动在工作区出现前干净跳过、不 226)+ 新单元
`chv-guest/chv-gitea-worker.path`(`PathExists=/home/chv/workspace`,
工作区一出现即触发启动;两者缺一不可——Condition 本身绝不重试)。
runcmd 只启动 .path 单元,不直接 start 服务;StartLimit 不放宽,
tmpfiles.d 不补工作区行(见服务单元注释)。
- `chv-guest/chv-sync-worker-client.py`(新,标准库薄客户端):
`chv-sync pull/push/status` 在 worker socket 存在时改走 worker
(发类型化请求、原样回显 worker 的 stdout/stderr、按 worker 的
@@ -156,7 +162,9 @@ Base64、零宽字符)、藏在图片/附件/二进制里的指令、需要理
## 4. 真机待验证清单(等测试机空闲,排队在 round-11 之后)
- worker 在 lite12 镜像里的启动时序(须在 broker/`chv-sync` 调用
之前就绪;与 P3 authd 的启动顺序关系)。
之前就绪;与 P3 authd 的启动顺序关系)。round-12 修复轮第三轮
(缺口 ①)已改 Condition + .path 触发,待真机复测 3 验证 5 台
VM 0 failed。
- worker 的 systemd 沙箱在真机上生效(`systemctl status`、cgroup
路径、受限调用被挡的表现)。
- broker → worker → helper → authd → git 全链路在真机上跑通