oh-my-openagent Linux supervisor 挂起修复验收IC-8 截止时刻、进程组终止与统计验证【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent导读本文基于 oh-my-openagent 仓库中的验收证据文档 criteria-linux.md完整呈现 memory-run supervisor内存运行监督进程在 Linux 上挂满 60000ms 超时上限问题的五项验收标准、三臂统计实验结论以及背后的源码级实现原理。读完本文你将掌握该修复的验收方法论截止时刻注入、孤儿进程检查、回归面覆盖、对抗性审计、n60 统计验证并能在仓库中定位对应的测试与实现代码自行复现验收流程。问题背景supervisor 挂满 60 秒超时上限oh-my-openagent 的 memory-run supervisor实现于 memory-run-supervisor.ts负责在受控环境中启动模型子进程、执行超时宽限与进程组终止并最终发布运行结果run outcome。验收文档记录的问题是在 Linux 上进程终止链路曾在多组场景下整体挂满60000ms的超时上限ceiling而非按预期的截止时刻deadline instant在毫秒级完成优雅/硬性树终止。验收环境固定为容器镜像oven/bun:1.3.12-debian工作区以复制方式not bind-mounted放入容器源码最终版本提交2752ad20f。验收文档将修复目标拆解为五个标准Criterion 1–5逐项以测试输出、孤儿进程检查和提交审计作为证据最后以真实 Linux 上的三臂统计实验量化修复收益。Criterion 12截止时刻在 posix / win32 双平台分支上生效第一条与第二条标准验证的是同一件事的两个平台分支向 supervisor 注入inject平台分支后优雅终止graceful termination与硬性树终止hard tree termination都必须使用被注入的绝对截止时刻deadline instants而不是各自重新计时或误用其他时钟源。文档给出的验收结果(pass) injected posix branch ... graceful and hard tree termination use those instants [92.00ms] (pass) injected win32 branch ... graceful and hard tree termination use those instants [123.00ms] 5 pass / 0 fail Ran 5 tests across 1 file. [532.00ms]修复后两组分支分别以92ms / 123ms完成终止流程而修复前同一批测试每一侧都挂满完整的60000ms上限Previously each hung for the full 60000ms ceiling。也就是说同样的断言、同样的注入分支超时从 60 秒级收敛到百毫秒级。对应的测试文件是 memory-run-supervisor.ic8.test.ts其中对IC8_PLATFORMS [posix, win32]两个平台分别运行两类用例注入平台分支 stubborn抗拒退出子进程推进注入时钟 2000ms 后等待posix-SIGTERM-pid.json或win32-graceful-pid.json落盘再推进 3000ms 验证outcome.json被写出且taskkill-invocation.json非 win32 场景不存在supervisor 被 SIGKILL 后由 bootstrap 独自执行持久化截止时刻验证 supervisor 崩溃后截止时刻约束仍由子进程侧的 bootstrap 强制执行。测试基架位于 memory-run-supervisor-ic8-harness.tslaunchSupervisor通过OMO_MEMORY_SUPERVISOR_ALLOW_TEST_SEAMS、OMO_MEMORY_SUPERVISOR_PLATFORM、OMO_MEMORY_SUPERVISOR_CLOCK_PATH等环境变量注入平台与时钟测试缝test seammakeRun生成的launch.json中写死hardDeadlineAt: 2_000、terminationGraceMs: 1_000构成一个2 秒硬截止 1 秒终止宽限的受控运行。Criterion 3忽略 SIGTERM 的子进程在宽限到期后被进程组杀死第三条标准覆盖一个典型的对抗场景子进程完全忽略 SIGTERM。此时优雅终止必然失效验收要求是——当终止宽限期termination grace耗尽时整个进程组被强制杀死且不留下孤儿进程(pass) #given a child that ignores SIGTERM #when termination grace expires #then the process group is killed [125.00ms] 1 pass / 0 fail orphan check (ps -eo pid,args | grep supervisor-child|child-bootstrap): NO ORPHANS测试描述本身即验收断言given / when / then宽限期到期 → 进程组被杀。修复后的执行耗时为 125ms。验收还额外做了孤儿进程检查通过ps -eo pid,args过滤supervisor-child与child-bootstrap两个角色确认零孤儿NO ORPHANS。进程组语义的实现位于 memory-run-supervisor-ic8-process-groups.tsterminateProcessGroupPOSIX 下process.kill(-pid, SIGKILL)对整个进程组发信号win32 下调用taskkill /pid pid /T /F且 taskkill 返回非零状态或报错时失败关闭fail closedprocessGroupIsAlive通过process.kill(pid, 0)探活win32 探单个 pidPOSIX 探-pid组 idEPERM视为存活validateProcessGroupPid拒绝非正整数 pid防止误杀。硬终止在 supervisor-process-identity.ts 的terminateSupervisorChildHard中实现win32 走taskkillTreePOSIX 走signalSupervisorProcessGroup(pid, SIGKILL)即process.kill(-pid, SIGKILL)。supervisor 进程还在exit、SIGTERM、SIGINT时同步执行containChild确保自身消亡时顺带清理子进程树。Criterion 4macOS 回归面由于修复涉及跨平台进程终止逻辑验收必须确认没有破坏 macOSdarwin这一回归面。文档给出的两处全量测试结果packages/memory-core : 481 pass 0 fail Ran 481 tests across 60 files. [75.54s] packages/omo-senpi/src/components/memory : 490 pass 0 fail Ran 490 tests across 90 files. [89.21s]packages/memory-core481 个测试、60 个文件全部通过packages/omo-senpi/src/components/memory490 个测试、90 个文件全部通过。两组均为 0 fail说明 supervisor 的时钟与终止逻辑变更没有引入 macOS 回归。Criterion 5对修复提交的对抗性审计第五条标准是对修复提交本身做对抗性审计adversarial audit防止通过弱化测试来假装修复的作弊路径禁止模式检查NONE—— 修复提交中未出现.skip/.only/xfail/ 抬高超时上限raised ceiling修复内容被描述为两次有界重读two bounded re-reads加上事件合并event coalescing明确声明未抬高上限、未跳过测试、未削弱任何断言、未移除任何 Linux 覆盖。这一审计保证了验收结果的归因干净性能提升来自实现修复而非测试让步。统计验证n60 三臂实验与拒绝的假设验收文档对最核心的注入 posix 分支的截止时刻用例做了真实 Linux 上的三臂统计实验每臂n60实验臂失败率说明HEAD修复前基线11/60 18.3%原始实现截止时刻偶发不触发 clock re-read时钟重读3/60 5.0%修复第一层有界时钟重读 wait-helper fix等待辅助修复0/60 0.0%修复完整形态两层叠加归零从 18.3% 到 5.0% 再到 0.0%每一层修复都带来可测量的失败率下降最终在 60 次采样中实现零失败。更有价值的是被测量并回退的备选假设Rejected hypotheses measured and reverted假设失败率结论cascade no-op级联空操作18/60被拒绝group-target hard kill改为对组目标硬杀11/60被拒绝test phase barrier测试阶段屏障12/60被拒绝这三条假设与最终采用的两层修复不同前者的失败率要么不低于基线11/60要么更高18/60、12/60。通过先测量、后采用、失败即回退的流程修复方案被收敛到唯一有效组合——clock re-read wait-helper。这一组数字也说明 Linux 上截止时刻失效是一个概率性问题约 18% 的用例会挂满 60s必须用统计手段而非单次偶发复现来验证。源码级原理有界重读与事件合并如何消灭 60s 挂起文档所述两次有界重读 事件合并在源码中有直接对应实现位于 supervisor-process-identity.ts 的scheduleSupervisorDeadline。该函数在测试缝启用时以注入时钟目录OMO_MEMORY_SUPERVISOR_CLOCK_PATH为时间源通过目录内readdirSync解析形如seq-timestamp的文件获取当前时刻readInjectedClock。其核心调度逻辑为事件驱动用watch(clockDir, check)监听时钟目录时钟文件每次写入都会触发check有界重读兜底clock re-read源码注释明确记录了修复动机——check 在目录读取尚未产生有限时刻时会直接退出bail而跨越截止时刻的那次写入通常是最后一次写入之后不再有任何事件到来去重试它于是截止时刻永远不触发。为此引入了setInterval(check, CLOCK_RECHECK_INTERVAL_MS)其中CLOCK_RECHECK_INTERVAL_MS 25每 25ms 主动重读一次时钟目录使截止时刻是否到达取决于时钟的值而非某一次目录读取是否恰好观察到写入。注释给出的实测对比是仅靠目录事件边沿edges在 Linux 上是 11/60 失败加上重读后降为 3/60——与验收文档统计完全吻合事件合并event coalescingcheck内部以settled标志去重一旦某个事件或重读确认时刻已到或 cancel 已执行后续事件一律短路避免同一个截止时刻被多次回调触发也避免 cancel 后残留的 watcher/interval 再次执行回调。两个截止时刻scheduleSupervisorDeadline(manifest.hardDeadlineAt, ...)与scheduleSupervisorDeadline(manifest.hardDeadlineAt manifest.terminationGraceMs, ...)分别在 supervisormemory-run-supervisor.ts与 bootstrap同文件runChildBootstrap两侧各注册一份形成双重保险即使 supervisor 本身死亡bootstrap 侧依然持有持久化的截止时刻launch.json中的hardDeadlineAt这正是 IC-8 用例supervisor 被 SIGKILL 后由 bootstrap 单独强制截止时刻验证的行为。另外outcome 的超时判定刻意不依赖哪个进程的回调先跑而是回读时钟readSupervisorClockNow()并判断clockNow manifest.hardDeadlineAtmemory-run-supervisor.ts避免 bootstrap 抢先结束子进程导致 supervisor 侧取消回调、从而擦除一个其实已被超出的截止时刻。如何在仓库中复现与进一步阅读验收证据原文.omo/evidence/20260812-linux-supervisor-hang/criteria-linux.mdIC-8 包含性测试memory-run-supervisor.ic8.test.ts5 个用例覆盖双平台注入、SIGKILL 兜底、资源清理、taskkill 失败关闭测试默认超时IC8_WAIT_MS 60_000即验收文档中60 秒上限的出处集成测试memory-run-supervisor.integration.test.ts驱动真实的 supervisor、bootstrap、模型子进程三者协作测试基架memory-run-supervisor-ic8-harness.ts 与 supervisor-test-signals.ts注入时钟与文件系统状态等待进程组原语memory-run-supervisor-ic8-process-groups.ts实现主体memory-run-supervisor.ts 与 supervisor-process-identity.ts。复现方式在oven/bun:1.3.12-debian容器中工作区复制进入、非 bind-mount与验收环境一致于仓库根目录执行上述.ic8.test.ts相关测试即可。需要说明的是验收文档记录的2752ad20f是当时的源码基线当前仓库已在此基础上继续演进实际测试输出可能略有差异但 IC-8 的验收断言与统计口径仍保持有效。总结这次 Linux supervisor 挂起修复的价值不在于某个单一改动而在于一套可复制的验收闭环以注入时钟制造确定性的截止时刻 → 以进程组语义保证硬终止无孤儿 → 以双平台与 macOS 全量测试守住回归面 → 以对抗性审计保证修复归因干净 → 以 n60 三臂统计量化每一层收益并回退无效假设。18.3% → 5.0% → 0.0% 的失败率曲线以及两次有界重读 事件合并最终胜出而三种备选假设被测量否决的过程为处理同类偶发性超时挂起问题提供了一个可以直接借鉴的工程范式。【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oh-my-openagent Linux supervisor 挂起修复验收：IC-8 截止时刻、进程组终止与统计验证
oh-my-openagent Linux supervisor 挂起修复验收IC-8 截止时刻、进程组终止与统计验证【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent导读本文基于 oh-my-openagent 仓库中的验收证据文档 criteria-linux.md完整呈现 memory-run supervisor内存运行监督进程在 Linux 上挂满 60000ms 超时上限问题的五项验收标准、三臂统计实验结论以及背后的源码级实现原理。读完本文你将掌握该修复的验收方法论截止时刻注入、孤儿进程检查、回归面覆盖、对抗性审计、n60 统计验证并能在仓库中定位对应的测试与实现代码自行复现验收流程。问题背景supervisor 挂满 60 秒超时上限oh-my-openagent 的 memory-run supervisor实现于 memory-run-supervisor.ts负责在受控环境中启动模型子进程、执行超时宽限与进程组终止并最终发布运行结果run outcome。验收文档记录的问题是在 Linux 上进程终止链路曾在多组场景下整体挂满60000ms的超时上限ceiling而非按预期的截止时刻deadline instant在毫秒级完成优雅/硬性树终止。验收环境固定为容器镜像oven/bun:1.3.12-debian工作区以复制方式not bind-mounted放入容器源码最终版本提交2752ad20f。验收文档将修复目标拆解为五个标准Criterion 1–5逐项以测试输出、孤儿进程检查和提交审计作为证据最后以真实 Linux 上的三臂统计实验量化修复收益。Criterion 12截止时刻在 posix / win32 双平台分支上生效第一条与第二条标准验证的是同一件事的两个平台分支向 supervisor 注入inject平台分支后优雅终止graceful termination与硬性树终止hard tree termination都必须使用被注入的绝对截止时刻deadline instants而不是各自重新计时或误用其他时钟源。文档给出的验收结果(pass) injected posix branch ... graceful and hard tree termination use those instants [92.00ms] (pass) injected win32 branch ... graceful and hard tree termination use those instants [123.00ms] 5 pass / 0 fail Ran 5 tests across 1 file. [532.00ms]修复后两组分支分别以92ms / 123ms完成终止流程而修复前同一批测试每一侧都挂满完整的60000ms上限Previously each hung for the full 60000ms ceiling。也就是说同样的断言、同样的注入分支超时从 60 秒级收敛到百毫秒级。对应的测试文件是 memory-run-supervisor.ic8.test.ts其中对IC8_PLATFORMS [posix, win32]两个平台分别运行两类用例注入平台分支 stubborn抗拒退出子进程推进注入时钟 2000ms 后等待posix-SIGTERM-pid.json或win32-graceful-pid.json落盘再推进 3000ms 验证outcome.json被写出且taskkill-invocation.json非 win32 场景不存在supervisor 被 SIGKILL 后由 bootstrap 独自执行持久化截止时刻验证 supervisor 崩溃后截止时刻约束仍由子进程侧的 bootstrap 强制执行。测试基架位于 memory-run-supervisor-ic8-harness.tslaunchSupervisor通过OMO_MEMORY_SUPERVISOR_ALLOW_TEST_SEAMS、OMO_MEMORY_SUPERVISOR_PLATFORM、OMO_MEMORY_SUPERVISOR_CLOCK_PATH等环境变量注入平台与时钟测试缝test seammakeRun生成的launch.json中写死hardDeadlineAt: 2_000、terminationGraceMs: 1_000构成一个2 秒硬截止 1 秒终止宽限的受控运行。Criterion 3忽略 SIGTERM 的子进程在宽限到期后被进程组杀死第三条标准覆盖一个典型的对抗场景子进程完全忽略 SIGTERM。此时优雅终止必然失效验收要求是——当终止宽限期termination grace耗尽时整个进程组被强制杀死且不留下孤儿进程(pass) #given a child that ignores SIGTERM #when termination grace expires #then the process group is killed [125.00ms] 1 pass / 0 fail orphan check (ps -eo pid,args | grep supervisor-child|child-bootstrap): NO ORPHANS测试描述本身即验收断言given / when / then宽限期到期 → 进程组被杀。修复后的执行耗时为 125ms。验收还额外做了孤儿进程检查通过ps -eo pid,args过滤supervisor-child与child-bootstrap两个角色确认零孤儿NO ORPHANS。进程组语义的实现位于 memory-run-supervisor-ic8-process-groups.tsterminateProcessGroupPOSIX 下process.kill(-pid, SIGKILL)对整个进程组发信号win32 下调用taskkill /pid pid /T /F且 taskkill 返回非零状态或报错时失败关闭fail closedprocessGroupIsAlive通过process.kill(pid, 0)探活win32 探单个 pidPOSIX 探-pid组 idEPERM视为存活validateProcessGroupPid拒绝非正整数 pid防止误杀。硬终止在 supervisor-process-identity.ts 的terminateSupervisorChildHard中实现win32 走taskkillTreePOSIX 走signalSupervisorProcessGroup(pid, SIGKILL)即process.kill(-pid, SIGKILL)。supervisor 进程还在exit、SIGTERM、SIGINT时同步执行containChild确保自身消亡时顺带清理子进程树。Criterion 4macOS 回归面由于修复涉及跨平台进程终止逻辑验收必须确认没有破坏 macOSdarwin这一回归面。文档给出的两处全量测试结果packages/memory-core : 481 pass 0 fail Ran 481 tests across 60 files. [75.54s] packages/omo-senpi/src/components/memory : 490 pass 0 fail Ran 490 tests across 90 files. [89.21s]packages/memory-core481 个测试、60 个文件全部通过packages/omo-senpi/src/components/memory490 个测试、90 个文件全部通过。两组均为 0 fail说明 supervisor 的时钟与终止逻辑变更没有引入 macOS 回归。Criterion 5对修复提交的对抗性审计第五条标准是对修复提交本身做对抗性审计adversarial audit防止通过弱化测试来假装修复的作弊路径禁止模式检查NONE—— 修复提交中未出现.skip/.only/xfail/ 抬高超时上限raised ceiling修复内容被描述为两次有界重读two bounded re-reads加上事件合并event coalescing明确声明未抬高上限、未跳过测试、未削弱任何断言、未移除任何 Linux 覆盖。这一审计保证了验收结果的归因干净性能提升来自实现修复而非测试让步。统计验证n60 三臂实验与拒绝的假设验收文档对最核心的注入 posix 分支的截止时刻用例做了真实 Linux 上的三臂统计实验每臂n60实验臂失败率说明HEAD修复前基线11/60 18.3%原始实现截止时刻偶发不触发 clock re-read时钟重读3/60 5.0%修复第一层有界时钟重读 wait-helper fix等待辅助修复0/60 0.0%修复完整形态两层叠加归零从 18.3% 到 5.0% 再到 0.0%每一层修复都带来可测量的失败率下降最终在 60 次采样中实现零失败。更有价值的是被测量并回退的备选假设Rejected hypotheses measured and reverted假设失败率结论cascade no-op级联空操作18/60被拒绝group-target hard kill改为对组目标硬杀11/60被拒绝test phase barrier测试阶段屏障12/60被拒绝这三条假设与最终采用的两层修复不同前者的失败率要么不低于基线11/60要么更高18/60、12/60。通过先测量、后采用、失败即回退的流程修复方案被收敛到唯一有效组合——clock re-read wait-helper。这一组数字也说明 Linux 上截止时刻失效是一个概率性问题约 18% 的用例会挂满 60s必须用统计手段而非单次偶发复现来验证。源码级原理有界重读与事件合并如何消灭 60s 挂起文档所述两次有界重读 事件合并在源码中有直接对应实现位于 supervisor-process-identity.ts 的scheduleSupervisorDeadline。该函数在测试缝启用时以注入时钟目录OMO_MEMORY_SUPERVISOR_CLOCK_PATH为时间源通过目录内readdirSync解析形如seq-timestamp的文件获取当前时刻readInjectedClock。其核心调度逻辑为事件驱动用watch(clockDir, check)监听时钟目录时钟文件每次写入都会触发check有界重读兜底clock re-read源码注释明确记录了修复动机——check 在目录读取尚未产生有限时刻时会直接退出bail而跨越截止时刻的那次写入通常是最后一次写入之后不再有任何事件到来去重试它于是截止时刻永远不触发。为此引入了setInterval(check, CLOCK_RECHECK_INTERVAL_MS)其中CLOCK_RECHECK_INTERVAL_MS 25每 25ms 主动重读一次时钟目录使截止时刻是否到达取决于时钟的值而非某一次目录读取是否恰好观察到写入。注释给出的实测对比是仅靠目录事件边沿edges在 Linux 上是 11/60 失败加上重读后降为 3/60——与验收文档统计完全吻合事件合并event coalescingcheck内部以settled标志去重一旦某个事件或重读确认时刻已到或 cancel 已执行后续事件一律短路避免同一个截止时刻被多次回调触发也避免 cancel 后残留的 watcher/interval 再次执行回调。两个截止时刻scheduleSupervisorDeadline(manifest.hardDeadlineAt, ...)与scheduleSupervisorDeadline(manifest.hardDeadlineAt manifest.terminationGraceMs, ...)分别在 supervisormemory-run-supervisor.ts与 bootstrap同文件runChildBootstrap两侧各注册一份形成双重保险即使 supervisor 本身死亡bootstrap 侧依然持有持久化的截止时刻launch.json中的hardDeadlineAt这正是 IC-8 用例supervisor 被 SIGKILL 后由 bootstrap 单独强制截止时刻验证的行为。另外outcome 的超时判定刻意不依赖哪个进程的回调先跑而是回读时钟readSupervisorClockNow()并判断clockNow manifest.hardDeadlineAtmemory-run-supervisor.ts避免 bootstrap 抢先结束子进程导致 supervisor 侧取消回调、从而擦除一个其实已被超出的截止时刻。如何在仓库中复现与进一步阅读验收证据原文.omo/evidence/20260812-linux-supervisor-hang/criteria-linux.mdIC-8 包含性测试memory-run-supervisor.ic8.test.ts5 个用例覆盖双平台注入、SIGKILL 兜底、资源清理、taskkill 失败关闭测试默认超时IC8_WAIT_MS 60_000即验收文档中60 秒上限的出处集成测试memory-run-supervisor.integration.test.ts驱动真实的 supervisor、bootstrap、模型子进程三者协作测试基架memory-run-supervisor-ic8-harness.ts 与 supervisor-test-signals.ts注入时钟与文件系统状态等待进程组原语memory-run-supervisor-ic8-process-groups.ts实现主体memory-run-supervisor.ts 与 supervisor-process-identity.ts。复现方式在oven/bun:1.3.12-debian容器中工作区复制进入、非 bind-mount与验收环境一致于仓库根目录执行上述.ic8.test.ts相关测试即可。需要说明的是验收文档记录的2752ad20f是当时的源码基线当前仓库已在此基础上继续演进实际测试输出可能略有差异但 IC-8 的验收断言与统计口径仍保持有效。总结这次 Linux supervisor 挂起修复的价值不在于某个单一改动而在于一套可复制的验收闭环以注入时钟制造确定性的截止时刻 → 以进程组语义保证硬终止无孤儿 → 以双平台与 macOS 全量测试守住回归面 → 以对抗性审计保证修复归因干净 → 以 n60 三臂统计量化每一层收益并回退无效假设。18.3% → 5.0% → 0.0% 的失败率曲线以及两次有界重读 事件合并最终胜出而三种备选假设被测量否决的过程为处理同类偶发性超时挂起问题提供了一个可以直接借鉴的工程范式。【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考