Skip to content

wanghai-tech / hikoon-ACR

Go to a project
Toggle navigation
Toggle navigation pinning
Commit d206f2c9 d206f2c91f2d39cfb54d67e8f6b7753715472167 by cnb.bofCdSsphPA
Options

Harden the FMA waiter by launching it as a real detached guard 

Constraint: A multi-hour download needs a background guard that survives shell teardown, not just a logically correct polling loop.
Rejected: More ad-hoc nohup restarts | They obscured whether the issue was loop logic or process detachment.
Confidence: high
Scope-risk: narrow
Directive: Use the guard launcher for future unattended waits and keep pid/log artifacts so later sessions can verify liveness quickly.
Tested: Ran a foreground three-cycle control experiment, launched the new setsid-based guard, then verified the detached process survived with PPID 1 and emitted at least two polling cycles in the log.
Not-tested: Full handoff through completed download, extraction, and smoke still awaits archive completion.
1 parent 847ac44d
Inline Side-by-side
Showing 2 changed files with 225 additions and 0 deletions
#!/usr/bin/env bash
set -euo pipefail
cd "$(dirname "$0")/.."
LOG_FILE=".omx_wait_for_fma.log"
PID_FILE=".omx_wait_for_fma.pid"
: > "$LOG_FILE"
setsid /usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 30 >> "$LOG_FILE" 2>&1 < /dev/null &
echo $! > "$PID_FILE"
echo "$!"
......@@ -2,6 +2,33 @@
## 2026-06-02
### Stage: 真实 FMA 后台守护方式稳定化
完成项：
- 对 `wait_for_fma_and_prepare.py` 做前台多轮复现实验，确认逻辑本身不是“首轮即崩”
- 判断二次掉线更可能来自后台脱离方式而非轮询逻辑
- 新增 `acr-engine/scripts/start_wait_for_fma_guard.sh`，使用 `setsid` + 明确工作目录 + pid/log 文件启动长期守护
- 验证新守护方式可跨多轮轮询持续存活
验证结果：
- 前台验证：
- `/usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 1 --max-cycles 3`
连续输出 3 轮 `polling`，并正常结束为 `status=waiting`
- 下载进度继续增长到：
- `4261445632 -> 4265574400`
- `55.4905% -> 55.5443%`
- 新守护脚本启动后：
- pid=`52277`
- `PPID=1`
- 进程状态仍存活
- 守护日志已连续输出至少两轮：
- `cycle=1`, `55.8297%`
- `cycle=2`, `57.0573%`
结论：
- 之前等待器掉线的主因更接近后台启动/脱离方式，而非轮询主循环本身
- 现在真实 FMA 自动承接链路已有更稳的守护启动入口
### Stage: 真实 FMA 长时等待器二次掉线复验
完成项：
......@@ -1016,6 +1043,33 @@
## 2026-06-02
### Stage: 真实 FMA 后台守护方式稳定化
完成项：
- 对 `wait_for_fma_and_prepare.py` 做前台多轮复现实验，确认逻辑本身不是“首轮即崩”
- 判断二次掉线更可能来自后台脱离方式而非轮询逻辑
- 新增 `acr-engine/scripts/start_wait_for_fma_guard.sh`，使用 `setsid` + 明确工作目录 + pid/log 文件启动长期守护
- 验证新守护方式可跨多轮轮询持续存活
验证结果：
- 前台验证：
- `/usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 1 --max-cycles 3`
连续输出 3 轮 `polling`，并正常结束为 `status=waiting`
- 下载进度继续增长到：
- `4261445632 -> 4265574400`
- `55.4905% -> 55.5443%`
- 新守护脚本启动后：
- pid=`52277`
- `PPID=1`
- 进程状态仍存活
- 守护日志已连续输出至少两轮：
- `cycle=1`, `55.8297%`
- `cycle=2`, `57.0573%`
结论：
- 之前等待器掉线的主因更接近后台启动/脱离方式，而非轮询主循环本身
- 现在真实 FMA 自动承接链路已有更稳的守护启动入口
### Stage: 真实 FMA 长时等待器二次掉线复验
完成项：
......@@ -1240,6 +1294,33 @@
## 2026-06-02
### Stage: 真实 FMA 后台守护方式稳定化
完成项：
- 对 `wait_for_fma_and_prepare.py` 做前台多轮复现实验，确认逻辑本身不是“首轮即崩”
- 判断二次掉线更可能来自后台脱离方式而非轮询逻辑
- 新增 `acr-engine/scripts/start_wait_for_fma_guard.sh`，使用 `setsid` + 明确工作目录 + pid/log 文件启动长期守护
- 验证新守护方式可跨多轮轮询持续存活
验证结果：
- 前台验证：
- `/usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 1 --max-cycles 3`
连续输出 3 轮 `polling`，并正常结束为 `status=waiting`
- 下载进度继续增长到：
- `4261445632 -> 4265574400`
- `55.4905% -> 55.5443%`
- 新守护脚本启动后：
- pid=`52277`
- `PPID=1`
- 进程状态仍存活
- 守护日志已连续输出至少两轮：
- `cycle=1`, `55.8297%`
- `cycle=2`, `57.0573%`
结论：
- 之前等待器掉线的主因更接近后台启动/脱离方式，而非轮询主循环本身
- 现在真实 FMA 自动承接链路已有更稳的守护启动入口
### Stage: 真实 FMA 长时等待器二次掉线复验
完成项：
......@@ -1474,6 +1555,33 @@
## 2026-06-02
### Stage: 真实 FMA 后台守护方式稳定化
完成项：
- 对 `wait_for_fma_and_prepare.py` 做前台多轮复现实验，确认逻辑本身不是“首轮即崩”
- 判断二次掉线更可能来自后台脱离方式而非轮询逻辑
- 新增 `acr-engine/scripts/start_wait_for_fma_guard.sh`，使用 `setsid` + 明确工作目录 + pid/log 文件启动长期守护
- 验证新守护方式可跨多轮轮询持续存活
验证结果：
- 前台验证：
- `/usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 1 --max-cycles 3`
连续输出 3 轮 `polling`，并正常结束为 `status=waiting`
- 下载进度继续增长到：
- `4261445632 -> 4265574400`
- `55.4905% -> 55.5443%`
- 新守护脚本启动后：
- pid=`52277`
- `PPID=1`
- 进程状态仍存活
- 守护日志已连续输出至少两轮：
- `cycle=1`, `55.8297%`
- `cycle=2`, `57.0573%`
结论：
- 之前等待器掉线的主因更接近后台启动/脱离方式，而非轮询主循环本身
- 现在真实 FMA 自动承接链路已有更稳的守护启动入口
### Stage: 真实 FMA 长时等待器二次掉线复验
完成项：
......@@ -1698,6 +1806,33 @@
## 2026-06-02
### Stage: 真实 FMA 后台守护方式稳定化
完成项：
- 对 `wait_for_fma_and_prepare.py` 做前台多轮复现实验，确认逻辑本身不是“首轮即崩”
- 判断二次掉线更可能来自后台脱离方式而非轮询逻辑
- 新增 `acr-engine/scripts/start_wait_for_fma_guard.sh`，使用 `setsid` + 明确工作目录 + pid/log 文件启动长期守护
- 验证新守护方式可跨多轮轮询持续存活
验证结果：
- 前台验证：
- `/usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 1 --max-cycles 3`
连续输出 3 轮 `polling`，并正常结束为 `status=waiting`
- 下载进度继续增长到：
- `4261445632 -> 4265574400`
- `55.4905% -> 55.5443%`
- 新守护脚本启动后：
- pid=`52277`
- `PPID=1`
- 进程状态仍存活
- 守护日志已连续输出至少两轮：
- `cycle=1`, `55.8297%`
- `cycle=2`, `57.0573%`
结论：
- 之前等待器掉线的主因更接近后台启动/脱离方式，而非轮询主循环本身
- 现在真实 FMA 自动承接链路已有更稳的守护启动入口
### Stage: 真实 FMA 长时等待器二次掉线复验
完成项：
......@@ -1920,6 +2055,33 @@
## 2026-06-02
### Stage: 真实 FMA 后台守护方式稳定化
完成项：
- 对 `wait_for_fma_and_prepare.py` 做前台多轮复现实验，确认逻辑本身不是“首轮即崩”
- 判断二次掉线更可能来自后台脱离方式而非轮询逻辑
- 新增 `acr-engine/scripts/start_wait_for_fma_guard.sh`，使用 `setsid` + 明确工作目录 + pid/log 文件启动长期守护
- 验证新守护方式可跨多轮轮询持续存活
验证结果：
- 前台验证：
- `/usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 1 --max-cycles 3`
连续输出 3 轮 `polling`，并正常结束为 `status=waiting`
- 下载进度继续增长到：
- `4261445632 -> 4265574400`
- `55.4905% -> 55.5443%`
- 新守护脚本启动后：
- pid=`52277`
- `PPID=1`
- 进程状态仍存活
- 守护日志已连续输出至少两轮：
- `cycle=1`, `55.8297%`
- `cycle=2`, `57.0573%`
结论：
- 之前等待器掉线的主因更接近后台启动/脱离方式，而非轮询主循环本身
- 现在真实 FMA 自动承接链路已有更稳的守护启动入口
### Stage: 真实 FMA 长时等待器二次掉线复验
完成项：
......@@ -2140,6 +2302,33 @@
## 2026-06-02
### Stage: 真实 FMA 后台守护方式稳定化
完成项：
- 对 `wait_for_fma_and_prepare.py` 做前台多轮复现实验，确认逻辑本身不是“首轮即崩”
- 判断二次掉线更可能来自后台脱离方式而非轮询逻辑
- 新增 `acr-engine/scripts/start_wait_for_fma_guard.sh`，使用 `setsid` + 明确工作目录 + pid/log 文件启动长期守护
- 验证新守护方式可跨多轮轮询持续存活
验证结果：
- 前台验证：
- `/usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 1 --max-cycles 3`
连续输出 3 轮 `polling`，并正常结束为 `status=waiting`
- 下载进度继续增长到：
- `4261445632 -> 4265574400`
- `55.4905% -> 55.5443%`
- 新守护脚本启动后：
- pid=`52277`
- `PPID=1`
- 进程状态仍存活
- 守护日志已连续输出至少两轮：
- `cycle=1`, `55.8297%`
- `cycle=2`, `57.0573%`
结论：
- 之前等待器掉线的主因更接近后台启动/脱离方式，而非轮询主循环本身
- 现在真实 FMA 自动承接链路已有更稳的守护启动入口
### Stage: 真实 FMA 长时等待器二次掉线复验
完成项：
......@@ -2365,6 +2554,33 @@
## 2026-06-02
### Stage: 真实 FMA 后台守护方式稳定化
完成项：
- 对 `wait_for_fma_and_prepare.py` 做前台多轮复现实验，确认逻辑本身不是“首轮即崩”
- 判断二次掉线更可能来自后台脱离方式而非轮询逻辑
- 新增 `acr-engine/scripts/start_wait_for_fma_guard.sh`，使用 `setsid` + 明确工作目录 + pid/log 文件启动长期守护
- 验证新守护方式可跨多轮轮询持续存活
验证结果：
- 前台验证：
- `/usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 1 --max-cycles 3`
连续输出 3 轮 `polling`，并正常结束为 `status=waiting`
- 下载进度继续增长到：
- `4261445632 -> 4265574400`
- `55.4905% -> 55.5443%`
- 新守护脚本启动后：
- pid=`52277`
- `PPID=1`
- 进程状态仍存活
- 守护日志已连续输出至少两轮：
- `cycle=1`, `55.8297%`
- `cycle=2`, `57.0573%`
结论：
- 之前等待器掉线的主因更接近后台启动/脱离方式，而非轮询主循环本身
- 现在真实 FMA 自动承接链路已有更稳的守护启动入口
### Stage: 真实 FMA 长时等待器二次掉线复验
完成项：
......