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
1 #!/usr/bin/env bash
2 set -euo pipefail
3 cd "$(dirname "$0")/.."
4 LOG_FILE=".omx_wait_for_fma.log"
5 PID_FILE=".omx_wait_for_fma.pid"
6 : > "$LOG_FILE"
7 setsid /usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 30 >> "$LOG_FILE" 2>&1 < /dev/null &
8 echo $! > "$PID_FILE"
9 echo "$!"
...@@ -2,6 +2,33 @@ ...@@ -2,6 +2,33 @@
2 2
3 ## 2026-06-02 3 ## 2026-06-02
4 4
5 ### Stage: 真实 FMA 后台守护方式稳定化
6
7 完成项：
8 - 对 `wait_for_fma_and_prepare.py` 做前台多轮复现实验，确认逻辑本身不是“首轮即崩”
9 - 判断二次掉线更可能来自后台脱离方式而非轮询逻辑
10 - 新增 `acr-engine/scripts/start_wait_for_fma_guard.sh`，使用 `setsid` + 明确工作目录 + pid/log 文件启动长期守护
11 - 验证新守护方式可跨多轮轮询持续存活
12
13 验证结果：
14 - 前台验证：
15 - `/usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 1 --max-cycles 3`
16 连续输出 3 轮 `polling`，并正常结束为 `status=waiting`
17 - 下载进度继续增长到：
18 - `4261445632 -> 4265574400`
19 - `55.4905% -> 55.5443%`
20 - 新守护脚本启动后：
21 - pid=`52277`
22 - `PPID=1`
23 - 进程状态仍存活
24 - 守护日志已连续输出至少两轮：
25 - `cycle=1`, `55.8297%`
26 - `cycle=2`, `57.0573%`
27
28 结论：
29 - 之前等待器掉线的主因更接近后台启动/脱离方式，而非轮询主循环本身
30 - 现在真实 FMA 自动承接链路已有更稳的守护启动入口
31
5 ### Stage: 真实 FMA 长时等待器二次掉线复验 32 ### Stage: 真实 FMA 长时等待器二次掉线复验
6 33
7 完成项： 34 完成项：
...@@ -1016,6 +1043,33 @@ ...@@ -1016,6 +1043,33 @@
1016 1043
1017 ## 2026-06-02 1044 ## 2026-06-02
1018 1045
1046 ### Stage: 真实 FMA 后台守护方式稳定化
1047
1048 完成项：
1049 - 对 `wait_for_fma_and_prepare.py` 做前台多轮复现实验，确认逻辑本身不是“首轮即崩”
1050 - 判断二次掉线更可能来自后台脱离方式而非轮询逻辑
1051 - 新增 `acr-engine/scripts/start_wait_for_fma_guard.sh`，使用 `setsid` + 明确工作目录 + pid/log 文件启动长期守护
1052 - 验证新守护方式可跨多轮轮询持续存活
1053
1054 验证结果：
1055 - 前台验证：
1056 - `/usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 1 --max-cycles 3`
1057 连续输出 3 轮 `polling`，并正常结束为 `status=waiting`
1058 - 下载进度继续增长到：
1059 - `4261445632 -> 4265574400`
1060 - `55.4905% -> 55.5443%`
1061 - 新守护脚本启动后：
1062 - pid=`52277`
1063 - `PPID=1`
1064 - 进程状态仍存活
1065 - 守护日志已连续输出至少两轮：
1066 - `cycle=1`, `55.8297%`
1067 - `cycle=2`, `57.0573%`
1068
1069 结论：
1070 - 之前等待器掉线的主因更接近后台启动/脱离方式，而非轮询主循环本身
1071 - 现在真实 FMA 自动承接链路已有更稳的守护启动入口
1072
1019 ### Stage: 真实 FMA 长时等待器二次掉线复验 1073 ### Stage: 真实 FMA 长时等待器二次掉线复验
1020 1074
1021 完成项： 1075 完成项：
...@@ -1240,6 +1294,33 @@ ...@@ -1240,6 +1294,33 @@
1240 1294
1241 ## 2026-06-02 1295 ## 2026-06-02
1242 1296
1297 ### Stage: 真实 FMA 后台守护方式稳定化
1298
1299 完成项：
1300 - 对 `wait_for_fma_and_prepare.py` 做前台多轮复现实验，确认逻辑本身不是“首轮即崩”
1301 - 判断二次掉线更可能来自后台脱离方式而非轮询逻辑
1302 - 新增 `acr-engine/scripts/start_wait_for_fma_guard.sh`，使用 `setsid` + 明确工作目录 + pid/log 文件启动长期守护
1303 - 验证新守护方式可跨多轮轮询持续存活
1304
1305 验证结果：
1306 - 前台验证：
1307 - `/usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 1 --max-cycles 3`
1308 连续输出 3 轮 `polling`，并正常结束为 `status=waiting`
1309 - 下载进度继续增长到：
1310 - `4261445632 -> 4265574400`
1311 - `55.4905% -> 55.5443%`
1312 - 新守护脚本启动后：
1313 - pid=`52277`
1314 - `PPID=1`
1315 - 进程状态仍存活
1316 - 守护日志已连续输出至少两轮：
1317 - `cycle=1`, `55.8297%`
1318 - `cycle=2`, `57.0573%`
1319
1320 结论：
1321 - 之前等待器掉线的主因更接近后台启动/脱离方式，而非轮询主循环本身
1322 - 现在真实 FMA 自动承接链路已有更稳的守护启动入口
1323
1243 ### Stage: 真实 FMA 长时等待器二次掉线复验 1324 ### Stage: 真实 FMA 长时等待器二次掉线复验
1244 1325
1245 完成项： 1326 完成项：
...@@ -1474,6 +1555,33 @@ ...@@ -1474,6 +1555,33 @@
1474 1555
1475 ## 2026-06-02 1556 ## 2026-06-02
1476 1557
1558 ### Stage: 真实 FMA 后台守护方式稳定化
1559
1560 完成项：
1561 - 对 `wait_for_fma_and_prepare.py` 做前台多轮复现实验，确认逻辑本身不是“首轮即崩”
1562 - 判断二次掉线更可能来自后台脱离方式而非轮询逻辑
1563 - 新增 `acr-engine/scripts/start_wait_for_fma_guard.sh`，使用 `setsid` + 明确工作目录 + pid/log 文件启动长期守护
1564 - 验证新守护方式可跨多轮轮询持续存活
1565
1566 验证结果：
1567 - 前台验证：
1568 - `/usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 1 --max-cycles 3`
1569 连续输出 3 轮 `polling`，并正常结束为 `status=waiting`
1570 - 下载进度继续增长到：
1571 - `4261445632 -> 4265574400`
1572 - `55.4905% -> 55.5443%`
1573 - 新守护脚本启动后：
1574 - pid=`52277`
1575 - `PPID=1`
1576 - 进程状态仍存活
1577 - 守护日志已连续输出至少两轮：
1578 - `cycle=1`, `55.8297%`
1579 - `cycle=2`, `57.0573%`
1580
1581 结论：
1582 - 之前等待器掉线的主因更接近后台启动/脱离方式，而非轮询主循环本身
1583 - 现在真实 FMA 自动承接链路已有更稳的守护启动入口
1584
1477 ### Stage: 真实 FMA 长时等待器二次掉线复验 1585 ### Stage: 真实 FMA 长时等待器二次掉线复验
1478 1586
1479 完成项： 1587 完成项：
...@@ -1698,6 +1806,33 @@ ...@@ -1698,6 +1806,33 @@
1698 1806
1699 ## 2026-06-02 1807 ## 2026-06-02
1700 1808
1809 ### Stage: 真实 FMA 后台守护方式稳定化
1810
1811 完成项：
1812 - 对 `wait_for_fma_and_prepare.py` 做前台多轮复现实验，确认逻辑本身不是“首轮即崩”
1813 - 判断二次掉线更可能来自后台脱离方式而非轮询逻辑
1814 - 新增 `acr-engine/scripts/start_wait_for_fma_guard.sh`，使用 `setsid` + 明确工作目录 + pid/log 文件启动长期守护
1815 - 验证新守护方式可跨多轮轮询持续存活
1816
1817 验证结果：
1818 - 前台验证：
1819 - `/usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 1 --max-cycles 3`
1820 连续输出 3 轮 `polling`，并正常结束为 `status=waiting`
1821 - 下载进度继续增长到：
1822 - `4261445632 -> 4265574400`
1823 - `55.4905% -> 55.5443%`
1824 - 新守护脚本启动后：
1825 - pid=`52277`
1826 - `PPID=1`
1827 - 进程状态仍存活
1828 - 守护日志已连续输出至少两轮：
1829 - `cycle=1`, `55.8297%`
1830 - `cycle=2`, `57.0573%`
1831
1832 结论：
1833 - 之前等待器掉线的主因更接近后台启动/脱离方式，而非轮询主循环本身
1834 - 现在真实 FMA 自动承接链路已有更稳的守护启动入口
1835
1701 ### Stage: 真实 FMA 长时等待器二次掉线复验 1836 ### Stage: 真实 FMA 长时等待器二次掉线复验
1702 1837
1703 完成项： 1838 完成项：
...@@ -1920,6 +2055,33 @@ ...@@ -1920,6 +2055,33 @@
1920 2055
1921 ## 2026-06-02 2056 ## 2026-06-02
1922 2057
2058 ### Stage: 真实 FMA 后台守护方式稳定化
2059
2060 完成项：
2061 - 对 `wait_for_fma_and_prepare.py` 做前台多轮复现实验，确认逻辑本身不是“首轮即崩”
2062 - 判断二次掉线更可能来自后台脱离方式而非轮询逻辑
2063 - 新增 `acr-engine/scripts/start_wait_for_fma_guard.sh`，使用 `setsid` + 明确工作目录 + pid/log 文件启动长期守护
2064 - 验证新守护方式可跨多轮轮询持续存活
2065
2066 验证结果：
2067 - 前台验证：
2068 - `/usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 1 --max-cycles 3`
2069 连续输出 3 轮 `polling`，并正常结束为 `status=waiting`
2070 - 下载进度继续增长到：
2071 - `4261445632 -> 4265574400`
2072 - `55.4905% -> 55.5443%`
2073 - 新守护脚本启动后：
2074 - pid=`52277`
2075 - `PPID=1`
2076 - 进程状态仍存活
2077 - 守护日志已连续输出至少两轮：
2078 - `cycle=1`, `55.8297%`
2079 - `cycle=2`, `57.0573%`
2080
2081 结论：
2082 - 之前等待器掉线的主因更接近后台启动/脱离方式，而非轮询主循环本身
2083 - 现在真实 FMA 自动承接链路已有更稳的守护启动入口
2084
1923 ### Stage: 真实 FMA 长时等待器二次掉线复验 2085 ### Stage: 真实 FMA 长时等待器二次掉线复验
1924 2086
1925 完成项： 2087 完成项：
...@@ -2140,6 +2302,33 @@ ...@@ -2140,6 +2302,33 @@
2140 2302
2141 ## 2026-06-02 2303 ## 2026-06-02
2142 2304
2305 ### Stage: 真实 FMA 后台守护方式稳定化
2306
2307 完成项：
2308 - 对 `wait_for_fma_and_prepare.py` 做前台多轮复现实验，确认逻辑本身不是“首轮即崩”
2309 - 判断二次掉线更可能来自后台脱离方式而非轮询逻辑
2310 - 新增 `acr-engine/scripts/start_wait_for_fma_guard.sh`，使用 `setsid` + 明确工作目录 + pid/log 文件启动长期守护
2311 - 验证新守护方式可跨多轮轮询持续存活
2312
2313 验证结果：
2314 - 前台验证：
2315 - `/usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 1 --max-cycles 3`
2316 连续输出 3 轮 `polling`，并正常结束为 `status=waiting`
2317 - 下载进度继续增长到：
2318 - `4261445632 -> 4265574400`
2319 - `55.4905% -> 55.5443%`
2320 - 新守护脚本启动后：
2321 - pid=`52277`
2322 - `PPID=1`
2323 - 进程状态仍存活
2324 - 守护日志已连续输出至少两轮：
2325 - `cycle=1`, `55.8297%`
2326 - `cycle=2`, `57.0573%`
2327
2328 结论：
2329 - 之前等待器掉线的主因更接近后台启动/脱离方式，而非轮询主循环本身
2330 - 现在真实 FMA 自动承接链路已有更稳的守护启动入口
2331
2143 ### Stage: 真实 FMA 长时等待器二次掉线复验 2332 ### Stage: 真实 FMA 长时等待器二次掉线复验
2144 2333
2145 完成项： 2334 完成项：
...@@ -2365,6 +2554,33 @@ ...@@ -2365,6 +2554,33 @@
2365 2554
2366 ## 2026-06-02 2555 ## 2026-06-02
2367 2556
2557 ### Stage: 真实 FMA 后台守护方式稳定化
2558
2559 完成项：
2560 - 对 `wait_for_fma_and_prepare.py` 做前台多轮复现实验，确认逻辑本身不是“首轮即崩”
2561 - 判断二次掉线更可能来自后台脱离方式而非轮询逻辑
2562 - 新增 `acr-engine/scripts/start_wait_for_fma_guard.sh`，使用 `setsid` + 明确工作目录 + pid/log 文件启动长期守护
2563 - 验证新守护方式可跨多轮轮询持续存活
2564
2565 验证结果：
2566 - 前台验证：
2567 - `/usr/local/miniconda3/bin/python -u scripts/wait_for_fma_and_prepare.py --interval 1 --max-cycles 3`
2568 连续输出 3 轮 `polling`，并正常结束为 `status=waiting`
2569 - 下载进度继续增长到：
2570 - `4261445632 -> 4265574400`
2571 - `55.4905% -> 55.5443%`
2572 - 新守护脚本启动后：
2573 - pid=`52277`
2574 - `PPID=1`
2575 - 进程状态仍存活
2576 - 守护日志已连续输出至少两轮：
2577 - `cycle=1`, `55.8297%`
2578 - `cycle=2`, `57.0573%`
2579
2580 结论：
2581 - 之前等待器掉线的主因更接近后台启动/脱离方式，而非轮询主循环本身
2582 - 现在真实 FMA 自动承接链路已有更稳的守护启动入口
2583
2368 ### Stage: 真实 FMA 长时等待器二次掉线复验 2584 ### Stage: 真实 FMA 长时等待器二次掉线复验
2369 2585
2370 完成项： 2586 完成项：
......