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 项全过。
21 lines
1.1 KiB
SYSTEMD
21 lines
1.1 KiB
SYSTEMD
[Unit]
|
||
Description=Start chv-gitea-worker once the sync workspace exists (feat-chv-muse-p6)
|
||
# round-12 修复轮第三轮(缺口 ①):worker 的 ReadWritePaths 含
|
||
# /home/chv/workspace,systemd 建 mount namespace 时该路径必须已
|
||
# 存在;工作区由 cloud-final 的 chv-sync boot 克隆出来,晚于
|
||
# multi-user.target 约 9 秒(R12 复测 2:worker 07:23:31 首启
|
||
# 226,工作区 07:23:40.40 才出现,5 次启动预算同一秒内耗尽)。
|
||
# 本单元只在工作区出现时触发服务启动——服务绝不在工作区出现前
|
||
# 启动,命名空间搭建前即有保证。须与服务的 ConditionPathExists
|
||
# 配对:Condition 挡住开机那次过早启动(干净跳过、不 226),本
|
||
# 单元提供 Condition 本身没有的“出现后再试一次”。
|
||
# 不用 StartLimit 放宽(仍是时序赌博,wake 时间在负载下已翻倍,
|
||
# 预算仍可能耗尽)与 tmpfiles 补行(/home/chv 本身晚于
|
||
# tmpfiles-setup,补了也没用),见服务单元 [Unit] 注释。
|
||
|
||
[Path]
|
||
PathExists=/home/chv/workspace
|
||
|
||
[Install]
|
||
WantedBy=multi-user.target
|