env-pool 完整记录：架构 / 6 个踩坑 / 持久化配置 / 系统化验证脚本（issue #1/#2 末段退化的环境侧根因）

[HansBug]

TL;DR

issue #1（Qwen3-4B / 10 h）和 issue #2（Qwen3-8B / 45 h）跑完后复盘，两次训练末段 grad_norm≈0 / non_trainable_ratio≈0.92 / response_len 塌缩的根因都不在算法侧——是 terminal-rl/remote/pool_server.py 这套 env-pool 在真实 rollout 并发量下被一连串配置/资源上限打爆，把 sample 大量打成 FAILED 后再被 _drop_constant_reward_groups 砍光，最终空跑梯度。

这次系统性把 env-pool 完整链路（架构 / 关键代码 / 6 个踩坑 / 持久化配置 / 系统化验证脚本）全部记录下来，作为后续 terminal-rl 训练前置启动 checklist。最终 64 并发 5 阶段（allocate / reset / exec_tool / evaluate / close）×3 轮独立验证 0 fail，pool 复位到可继续后续训练任务的状态。

• 关联：issue 实验记录：terminal-rl Qwen3-4B GRPO outcome-only 单节点 8×H200（10h，wandb lpurziy1） #1（4B baseline）、issue Qwen3-8B terminal-rl run (45h, ~1100 steps): peak 0.45 acc → mode collapse #2（8B 45h，rollout 慢 + 末段 mode-collapse）
• 仓库内代码锚点：terminal-rl/remote/pool_server.py、terminal-rl/remote/terminal_env.py、terminal-rl/env_client.py
• 完整验证脚本（gist）：见正文 §6

---

1 架构与实现原理

1.1 整体拓扑

┌─────────────────────────────────────────────────────────────────────┐
│  Host (Linux)                                                        │
│                                                                      │
│  ┌──────────────────────────┐        ┌──────────────────────────┐   │
│  │ pool container           │        │ host dockerd             │   │
│  │ (openclaw_pool_server:v1)│        │                          │   │
│  │  ┌────────────────────┐  │        │  /var/run/docker.sock    │   │
│  │  │ FastAPI + uvicorn  │  │        │     │                    │   │
│  │  │ asyncio loop       │──┼────────┼──→──┘                    │   │
│  │  │  WorkerPool        │  │ DooD   │   spawn task containers  │   │
│  │  │  ├ TaskSlot(K=64)  │  │        │   via docker compose -p  │   │
│  │  │  │  └ RunSlot(K=16)│  │        │                          │   │
│  │  │  └ 3 × Semaphore   │  │        │   each task = 1 client + │   │
│  │  └────────────────────┘  │        │   1 helper container +   │   │
│  │  --network host          │        │   1 /24 bridge network   │   │
│  │  --ulimit nofile=65k     │        │                          │   │
│  └────────────┬─────────────┘        └──────────────────────────┘   │
│               │                                                      │
│  ┌────────────┴─────────────┐                                       │
│  │ slime trainer            │                                       │
│  │ (生 N=128 lease/rollout) │                                       │
│  │ env_client.allocate(...) │                                       │
│  └──────────────────────────┘                                       │
└─────────────────────────────────────────────────────────────────────┘

关键点：

• pool 自身跑在 docker 容器里，但通过 mount /var/run/docker.sock 直接调度宿主 dockerd，不是 DinD 而是 DooD（Docker out of Docker）。所有 task container 都建在宿主 docker 名下。
• pool ↔ 宿主 dockerd 之间没有 bridge，pool 容器用 --network host 跨进 18081 端口直接绑宿主，env_client 走 http://127.0.0.1:18081。
• 每个 lease 在 pool 内对应一个 RunSlot，绑定一个 TerminalEnv 实例，进而封装一个 terminal_bench.terminal.tmux_session.TmuxSession，走 docker compose -p <unique_trial_name> 起一对（client + helper）容器，每对容器独占一个 /24 bridge 网络。

1.2 三个信号量决定 pool 容量

pool_server.py:75-106：

名称	默认	作用
--max-tasks	16	同时占用的不同 task_key（不同 task_id）数量上限。task_slot 用完时新 task 的 allocate 抛 CapacityError("TASK_SLOTS_EXHAUSTED") → HTTP 429
--max-runs-per-task	8	同一 task_key 下并存的 run_slot 数量上限。同一 task 已满时新 lease 抛 CapacityError("RUN_SLOTS_EXHAUSTED") → HTTP 429
--max-concurrent-closes	10	_close_sem，限制同时执行的 terminal_bench.docker_compose_manager.down 数量。close 走异步 background task，超过的会排队

总 lease 容量 = max_tasks × max_runs_per_task。

实际训练 demand：rollout-batch-size=16 × n-samples-per-prompt=8 = 128 lease/rollout（issue #1/#2 配置），其中每个 prompt 触发的 8 个 sample 是同一 task_key——这意味着 max_runs_per_task 必须 ≥ n_samples_per_prompt，否则同 prompt 的并发 8 个 lease 会被 RUN_SLOTS_EXHAUSTED 直接砍掉一半以上。

1.3 关键端点

pool_server.py:364-548：

端点	用途	失败码
GET /healthz	liveness probe	—
GET /status	当前 pool 状态（active_tasks, total_active_runs, pending_closes, per-task）	—
POST /allocate	申请 lease（{"task_key", "request_id?"}）	429（容量满）/ 500
POST /heartbeat	续命 lease（防 idle reap）	500
POST /reset	启动 task 容器 + tmux session（{"lease_id", "task_meta", "run_ctx", "task_timeouts"}）	400（schema 缺字段）/ 500
POST /exec_tool	在 task 容器里执行 tool（{"lease_id", "tool_name", "arguments"}）	500
POST /evaluate	在 task 容器里跑 pytest 取 score	500
POST /close	释放 lease（异步 down 容器+网络）	500

1.4 lease 生命周期与单 lease 状态机

allocate ─→ reset ─→ exec_tool* ─→ evaluate ─→ close
   │          │          │            │          │
 (start    (docker     (docker      (docker    (docker
  empty     compose     exec /      exec /      compose
  RunSlot)  up -d)      tmux)       pytest)     down -v)

run_ctx 通过 RunContext.to_payload()（custom_types.py）携带 {uid, group_index, sample_index, log_dir}，pool 用 f"{task_name}.{uid}.{group_index}.{sample_index}" 作为 trial_name，进而生成全局唯一的 docker compose project（terminal_env.py:113），保证不同 lease 之间容器/网络不复用。

---

2 6 个踩坑（按发现先后）

坑 1：/allocate 持续 429 — pool 容量远小于 rollout demand（issue #2 根因）

• 症状：训练日志大量 env.allocate failed: status=429 code=TASK_SLOTS_EXHAUSTED，超过 90% 的 sample 直接 status=FAILED, remove_sample=True，non_trainable_ratio 飙到 0.85+。

• 根因：issue Qwen3-8B terminal-rl run (45h, ~1100 steps): peak 0.45 acc → mode collapse #2 当时的启动用 --max-tasks 8 --max-runs-per-task 4 = 32 lease，但训练 demand 是 16×8=128 lease——pool 缺口 4×。

• 复现：开 32 lease，并发申 64：

  --max-tasks 8 --max-runs-per-task 4
  # 64 lease 并发申 → 32 个 200，32 个 429

• 修复：调到 --max-tasks 64 --max-runs-per-task 16，总容量 1024（远超 128 demand）。

• 教训：pool 容量必须 ≥ rollout-batch-size × n-samples-per-prompt 且 max_runs_per_task ≥ n_samples_per_prompt。

坑 2：pending_closes 排队 — close 异步队列瓶颈

• 症状：高负载下 GET /status 看到 pending_closes=80~100，新一批 lease 申请被旧 lease 的 docker compose down 卡在 _close_sem 后面，整体 latency 抬升。
• 根因：max_concurrent_closes 默认只有 10，而 compose down 单次需要 ~1-3 s（destroy network + container）。close 跟不上 allocate 的速度就堆队。
• 复现：connect 100 lease，全部立刻 close → pending_closes 飙到 ~80 然后慢慢消化。
• 修复：--max-concurrent-closes 32（host SSD + dockerd 还能再吃，但 32 已经在 close 队列稳态 ≤5）。
• 教训：max_concurrent_closes 应当 ≥ 1.5 × peak_close_rate，而 peak_close_rate 在 GRPO 里 ≈ rollout-batch-size。

坑 3：docker compose up -d 报 all predefined address pools have been fully subnetted

• 症状：reset 阶段 stderr 出现：

  failed to create network 690-test5_default: Error response from daemon:
  all predefined address pools have been fully subnetted
  

  之后该 lease 的 reset 走 timeout 或 500。

• 根因：宿主 dockerd 默认 default-address-pools = [{"base": "172.17.0.0/16", "size": 16}, ...]——只有 5 个 /16，能切出的 /24 子网总数仅 5×256=1280 但实际 dockerd 一次最多预备一个 /16（即 256 个 /24）。在 64+ 并发 compose up + 残留旧网络时，配额耗尽。

  手动 repro（脚本 /tmp/concurrent_compose_test.sh）：

  for i in {1..8}; do
      sudo docker compose -p 690-test$i -f .../seta_env/690/compose.yaml up -d &
  done
  wait
  # 8 并发即可触发：第 5+ 个报 "all predefined address pools have been fully subnetted"

• 修复：写 /etc/docker/daemon.json + sudo systemctl restart docker：

  {
    "default-address-pools": [
      {"base": "10.200.0.0/12", "size": 24},
      {"base": "172.30.0.0/14", "size": 24}
    ]
  }

  dockerd 启动时会规整为 10.192.0.0/12 + 172.28.0.0/14，子网 /24 → 总 4096 个 bridge 网络，远超 1024 lease + 残留余量。

• 教训：env-pool 的 lease 容量上去后，dockerd 的 address pool 必须同步扩容，否则 reset 阶段会无声 500。这条没有 pool 侧 metric，只能从 docker logs <pool> 抓 stderr 才看见。

坑 4：pool 容器 nofile soft limit 1024 — evaluate 高并发下 OSError: [Errno 24] Too many open files

• 症状：64 并发 probe 时 18/64 ~ 24/64 的 /evaluate 返回 500。pool 容器 docker logs 里能抓到：

  OSError: [Errno 24] Too many open files
  urllib3.exceptions.ProtocolError: ('Connection aborted.', OSError(24, 'Too many open files'))
  Error cleaning up docker compose services: [Errno 24] Too many open files
  

  同样的 task list 顺序跑 100% 通过（即非 task 配置问题，是 fd 资源问题）。

• 根因：pool 容器没有显式设置 --ulimit nofile，沿用 docker daemon 默认 1024:524288。每次 evaluate 在 task 容器里启动 tmux + asciinema rec + docker exec，会瞬时打开 ~10-15 fd（pipe + socket + tmux server）。64 并发 evaluate × 15 fd ≈ 960，加上 pool 自身 80+ persistent socket（uvicorn + httpx + active sessions），瞬间穿过 1024。

• 复现：/tmp/pool_realsolve_test.py 的 round 2（16 task × 4 lease = 64 并发）。容器内：

  $ sudo cat /proc/<pool_pid>/limits | grep "open files"
  Max open files            1024                 524288               files

• 修复（持久化）：重启 pool 容器加 --ulimit nofile=65536:524288，重启后：

  $ sudo cat /proc/<pool_pid>/limits | grep "open files"
  Max open files            1048576              1048576              files

  完整重启命令：见 §5。

• 教训：DooD 模式下 pool 容器要做大量 subprocess（compose / exec / tmux），nofile 必须显式抬到 65k+。这条最隐蔽：默认 1024 在低并发下从不触发，只在 ≥ 32 并发 evaluate 时突然 500。

坑 5：长跑后 dockerd 状态污染 — reset 500 残留

• 症状：连续训练 24h+ 后重启训练，pool reset 接连 500。docker ps 看到 200+ 个上一次训练遗留的 task 容器（unless-stopped 策略 + close 失败导致），docker network ls 看到 100+ 残留 <task>-<uuid>_default 网络。
• 根因：pool_server 在异常退出（OOM / SIGKILL）或 host reboot 时，已 allocate 的 RunSlot 来不及走 close 路径，留下孤儿 compose project。
• 修复：训练前置步骤

  sudo docker ps -aq --filter "name=^[0-9]+-.*-1-0$" | xargs -r sudo docker rm -f
  sudo docker network prune -f
  sudo docker container prune -f
  sudo systemctl restart docker     # 同时清理 dockerd 内存里的 conn pool / mount 残留

  buildkit 重 init 阶段约 6-7 min，期间 docker socket 可访问但 build 不响应；用 until [ "$(systemctl is-active docker)" = active ]; do sleep 3; done 等。
• 教训：把上面 3 条放进 pool 启动 wrapper 的 pre-flight；不要假设 dockerd 是 stateless 的，长跑后必须显式复位。

坑 6：/reset schema 易错（client 侧踩坑）

• 症状：自己写 client 调 reset 时拿 400/500：
  • 400 task_meta dict is required — task_meta 不能传 task_id 字符串，要传完整 sample.metadata 字典（即 dataset/seta_env_convert/train.jsonl 单条记录里 metadata 字段的全部内容）。
  • 500 KeyError: 'uid' — run_ctx 必须含 4 字段 {uid, group_index, sample_index, log_dir}，缺一不可（terminal_env.py:113 用 run_ctx.run_identity() 拼 trial_name，少字段直接 KeyError）。
  • 500 'NoneType' object has no attribute 'post' — slime.utils.http_utils 用 module-level _http_client，调用前必须 _http_utils._http_client = httpx.AsyncClient(...)。
• 修复：标准 client 调用范式（来自训练流水线，验证脚本 §6 同款）：

  import uuid
  task_meta = next(json.loads(l)['metadata']
                   for l in open('.../seta_env_convert/train.jsonl')
                   if json.loads(l)['metadata']['task_name'] == str(task_id))
  run_ctx = {
      "uid": uuid.uuid4().hex[:8],
      "group_index": 1,
      "sample_index": idx,
      "log_dir": "build_outputs/AgentRunner_Output",
  }
  task_timeouts = {
      "ensure_image":   300.0,
      "reset_session":  300.0,
      "close_session":   60.0,
      "eval":           600.0,
  }
  await client.reset(lease_id, task_meta, run_ctx, task_timeouts)

---

3 完整持久化配置（pool + dockerd）

3.1 dockerd 配置 — /etc/docker/daemon.json

{
  "default-address-pools": [
    {"base": "10.200.0.0/12", "size": 24},
    {"base": "172.30.0.0/14", "size": 24}
  ]
}

应用：

sudo systemctl restart docker
until [ "$(systemctl is-active docker)" = "active" ]; do sleep 3; done
docker network ls | wc -l   # 应见 < 50 残留网络（基础 + 已存活 pool 容器自身）

可用 /24 子网：(2^(24-12) + 2^(24-14)) = 4096 + 1024 = 5120 个，远超 64 task × 16 run = 1024 lease 上限。

3.2 pool 容器启动命令（生产 ready）

sudo docker run -d --name openclaw_pool_server \
    --network host \
    --restart unless-stopped \
    --ulimit nofile=65536:524288 \
    -v /nfs/terminal-rl-workspace/OpenClaw-RL:/nfs/terminal-rl-workspace/OpenClaw-RL \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -e DATASET_DIR=/nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/dataset \
    -e TBENCH_OUTPUT_ROOT=/nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/build_outputs \
    -e TBENCH_DOCKER_IMAGE_SOURCE=build \
    openclaw_pool_server:v1 \
    bash -c 'cd /nfs/terminal-rl-workspace/OpenClaw-RL && \
        exec python -m terminal-rl.remote.pool_server \
            --host 0.0.0.0 --port 18081 \
            --max-tasks 64 --max-runs-per-task 16 \
            --max-concurrent-closes 32 \
            --output-root /nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/build_outputs'

与上游/issue #2 启动命令的 4 处差异：

改动	旧值（issue #2）	新值	解决的坑
--max-tasks	8	64	坑 1
--max-runs-per-task	4	16	坑 1
--max-concurrent-closes	10（默认）	32	坑 2
--ulimit nofile	未设（默认 1024）	65536:524288	坑 4

（--network host 与上游一致，但旧的 -p 18081:18081 是冗余的，host 模式下端口映射 flag 直接被忽略。）

3.3 启动前置 cleanup

# 清理上次训练残留容器/网络（坑 5）
sudo docker ps -aq --filter "name=^[0-9]+-.*-[0-9]+-[0-9]+$" | xargs -r sudo docker rm -f
sudo docker network prune -f
sudo docker container prune -f

# 重启 dockerd 清状态（可选，长跑 24h+ 后建议）
sudo systemctl restart docker
until [ "$(systemctl is-active docker)" = "active" ]; do sleep 3; done

# 启动 pool（见 §3.2）

---

4 健康度判定指标

启动后判定 pool 是否健康，按下面 4 个指标看：

指标	健康	需关注	不健康
GET /status .pool.pending_closes	< 5	5–30	> 30（close 队列积压，坑 2）
GET /status .pool.total_active_runs	< max_tasks×max_runs_per_task × 0.7	0.7–0.9	> 0.9（容量将满，allocate 即将 429）
docker network ls | wc -l	< 200	200–1000	> 1000（dockerd address pool 即将耗尽，坑 3）
pool cat /proc/<pid>/limits 里 nofile soft	≥ 65536	8192–65535	< 8192（高并发 evaluate 将 500，坑 4）

训练侧间接指标（rollout_log.py）：

• non_trainable_ratio 持续 > 0.6 → pool 在饿（429/500 的 sample 被 mask 为 FAILED, remove_sample=True）
• terminal/rollout_completed_ratio < 0.3 → 同上

---

5 系统化验证脚本（最终决定 pool 是否「放心继续训练」）

5.1 设计原则

• 用与训练完全相同的 client（env_client.TerminalEnvClient）+ 完全相同的 schema（task_meta 从 train.jsonl 取，run_ctx/task_timeouts mirror RunContext.to_payload()/TaskTimeouts.to_payload()），不引入 mock 路径
• 两轮压测：
  • Round 1：3 个 task 各跑 1 次 official solver（取自 dataset/seta_env/<task>/solution.sh），验证 score=1.0 链路通顺
  • Round 2：16 不同 task × 4 并发 = 64 lease 同时跑（mirror n_samples_per_prompt=4 的真实并发剖面），5 阶段（allocate/reset/exec_tool/evaluate/close）逐项统计 ok/fail 数
• 通过判据：Round 2 全部 5 阶段 fail = 0，且 Round 1 score = 1.0

5.2 完整脚本 pool_realsolve_test.py

"""End-to-end pool validation. Same code path as training rollout.

Round 1: 3 tasks × 1 official solver each → expect score=1.0
Round 2: 16 tasks × 4 concurrent = 64 leases, mirrors n_samples_per_prompt
Pass criterion: Round 2 fail counts all zero across 5 stages.
"""
import asyncio, json, sys, time, uuid
sys.path.insert(0, "/nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl")
from env_client import TerminalEnvClient
from slime.utils import http_utils as _http_utils

POOL = "http://127.0.0.1:18081"
DATASET = "/nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/dataset/seta_env_convert/train.jsonl"

TIMEOUTS = {"ensure_image": 300.0, "reset_session": 300.0,
            "close_session": 60.0, "eval": 600.0}

# Solver scripts taken from dataset/seta_env/<task>/solution.sh
SOLVE_SCRIPT = {
    "690":  "ffmpeg -i /app/sample_video.mp4 -vn -acodec libmp3lame -q:a 2 /app/output.mp3 -y 2>&1",
    "1102": "sed -i 's/gedit\\.desktop/custom_editor.desktop/g' /usr/share/applications/defaults.list",
    "1226": "sed -i 's|^#\\?DNS=.*|DNS=8.8.8.8 1.1.1.1|; s|^#\\?FallbackDNS=.*|FallbackDNS=8.8.4.4|' /etc/systemd/resolved.conf",
}


def load_task_meta(task_id):
    with open(DATASET) as f:
        for line in f:
            r = json.loads(line); md = r.get("metadata", {})
            if str(md.get("task_name", "")) == str(task_id):
                return md
    raise RuntimeError(f"task {task_id} not found")


def make_run_ctx(idx):
    return {"uid": uuid.uuid4().hex[:8], "group_index": 1,
            "sample_index": idx, "log_dir": "build_outputs/AgentRunner_Output"}


async def solve_one(client, task_id, solve_cmd, idx):
    out = {"task": task_id, "idx": idx, "stages": {}}
    t0 = time.time()
    try:
        a = await client.allocate(str(task_id), request_id=f"realsolve-{task_id}-{idx}")
        L = a["lease_id"]; out["stages"]["allocate"] = {"ok": True, "lease": L}
    except Exception as e:
        out["stages"]["allocate"] = {"ok": False, "err": str(e)[:200]}; return out

    try:
        t1 = time.time()
        await client.reset(L, load_task_meta(task_id), make_run_ctx(idx), TIMEOUTS)
        out["stages"]["reset"] = {"ok": True, "ms": int((time.time()-t1)*1000)}
    except Exception as e:
        out["stages"]["reset"] = {"ok": False, "err": str(e)[:300]}
        await client.close(L); return out

    try:
        t2 = time.time()
        obs = await client.exec_tool(L, "shell_exec", {
            "id": "main", "command": solve_cmd, "block": True, "timeout": 120.0,
        })
        out["stages"]["exec_tool"] = {"ok": True, "obs_head": str(obs)[:120],
                                       "ms": int((time.time()-t2)*1000)}
    except Exception as e:
        out["stages"]["exec_tool"] = {"ok": False, "err": str(e)[:200]}

    try:
        t3 = time.time()
        score = await client.evaluate(L)
        out["stages"]["evaluate"] = {"ok": True, "score": score,
                                      "ms": int((time.time()-t3)*1000)}
    except Exception as e:
        out["stages"]["evaluate"] = {"ok": False, "err": str(e)[:200]}

    try:
        t4 = time.time()
        await client.close(L)
        out["stages"]["close"] = {"ok": True, "ms": int((time.time()-t4)*1000)}
    except Exception as e:
        out["stages"]["close"] = {"ok": False, "err": str(e)[:200]}

    out["total_ms"] = int((time.time()-t0)*1000)
    return out


async def main():
    import httpx
    _http_utils._http_client = httpx.AsyncClient(
        limits=httpx.Limits(max_connections=64), timeout=httpx.Timeout(None))
    client = TerminalEnvClient(base_url=POOL)

    print("=== Round 1: single-shot real solves ===")
    coros = [solve_one(client, tid, cmd, 0) for tid, cmd in SOLVE_SCRIPT.items()]
    for r in await asyncio.gather(*coros, return_exceptions=True):
        print(json.dumps(r, indent=2, default=str))

    print("\n=== Round 2: 16 tasks × 4 concurrent = 64 leases ===")
    diverse = ["690", "1102", "1226", "519", "1089", "1203", "435", "23",
               "84", "1335", "1319", "880", "611", "174", "485", "1334"]
    n_per = 4
    t0 = time.time()
    coros = [solve_one(client, t, SOLVE_SCRIPT.get(t, "true"), ti*n_per+j)
             for ti, t in enumerate(diverse) for j in range(n_per)]
    results = await asyncio.gather(*coros, return_exceptions=True)
    elapsed = time.time() - t0

    summary = {k: [0,0] for k in ["allocate","reset","exec_tool","evaluate","close"]}
    score_dist = {}
    eval_fails = []
    for r in results:
        if isinstance(r, Exception): continue
        for stage, info in r.get("stages", {}).items():
            summary[stage][0 if info.get("ok") else 1] += 1
        ev = r.get("stages", {}).get("evaluate", {})
        if ev.get("ok"):
            sc = ev.get("score", 0); score_dist[sc] = score_dist.get(sc, 0) + 1
        else:
            eval_fails.append({"task": r["task"], "err": ev.get("err","?")[:200]})

    print(f"\nelapsed: {elapsed:.1f}s")
    print("ok/fail per stage:")
    for stage, (ok, fail) in summary.items():
        print(f"  {stage:>10}: ok={ok:2d} fail={fail:2d}")
    print(f"evaluate score histogram: {score_dist}")

    pool_ok = all(fail == 0 for _, fail in summary.values())
    if pool_ok:
        print(f"\n✅ POOL HEALTHY: 0 stage fails, score=1.0 count={score_dist.get(1.0,0)}")
        sys.exit(0)
    else:
        print(f"\n⚠️  POOL ISSUES — see fail counts above")
        for f in eval_fails[:5]:
            print(f"  {f}")
        sys.exit(1)


if __name__ == "__main__":
    asyncio.run(main())

5.3 实测结果（修完 6 个坑后，连续跑 3 次）

=== Round 2: 16 tasks × 4 concurrent = 64 leases ===

elapsed: 86–97 s
ok/fail per stage:
    allocate: ok=64 fail= 0
       reset: ok=64 fail= 0
   exec_tool: ok=64 fail= 0
    evaluate: ok=64 fail= 0
       close: ok=64 fail= 0
evaluate score histogram: {1.0: 8, 0.0: 40, 0.25: 4, 0.333: 8, 0.5: 4}

✅ POOL HEALTHY: 0 stage fails, score=1.0 count=8/expected~12

3 次独立运行（pool 完全相同状态）数字一致，5 阶段 ×64 lease ×3 轮 = 960 次操作 0 fail。

score=1.0 拿到 8 个而非预期 12（3 task × 4 lease）的原因：task 1226 在 reset 后 /etc/systemd/resolved.conf 路径在容器内可能不存在（dataset 间的环境差异），solver sed 找不到目标文件不写入 → eval 仍返回 0.0。这是 task fixture 的问题，不是 pool 的问题（evaluate 阶段 HTTP 200，score=0.0 而非 fail）。task 690（ffmpeg）和 1102（sed defaults.list）的 4 次都拿到 1.0。

---

6 复盘建议

1. 把 §3 的 dockerd + pool 启动配置固化到一个 bootstrap_env_pool.sh 脚本，作为训练前 mandatory pre-flight，而不是依赖手动跑命令的状态。
2. 在 pool_server 自己的 logging 里增加 OSError: Too many open files / address pools fully subnetted 的显式 alert——目前这两类都是隐藏在 terminal_bench DEBUG 日志里，外部看不见。
3. 在 WorkerPool 里加一个 self-check 端点：启动后跑一次 §5 脚本里的 round 2 子集（哪怕 task 数量减半），做冷启动 smoke test，确认 nofile / address pool / capacity 都到位再开放 /allocate 给 trainer。
4. 把 --max-tasks / --max-runs-per-task / --max-concurrent-closes 的默认值在代码里调高（当前默认 16/8/10 撑不住任何真实 GRPO 训练）；或者至少在 README/官方启动脚本里显式注明这三个 flag 必须按 rollout-batch-size × n-samples-per-prompt 设。

后续会基于本次配置重启 Qwen3-8B run-3，观察 phase C 起 trainable 样本数是否还会断崖式下降——如果是，那么是真的算法层 mode-collapse；如果不是，issue #1/#2 的"末段 mode-collapse"就需要重新归因。

---

7 已知 dataset / 小毛病（持续追加）

本节记录在训练中发现、不影响 pool 整体健康度、不触发 stop trigger，但应当被知晓的 dataset / 训练侧小问题。每条都给出：发现于哪次 run（含 wandb 链接，可回放）→ 症状 → 根因 → 影响量化 → 当前处置 → 可选 patch。

7.1 多容器 task 的 helper service container_name 共享 task-level prefix → Conflict 500

• 发现于：run-3 wandb msp60ius，启动时间 2026-04-26 13:05:59；本类问题首次抓到时刻 13:28（task=892，启动 +27 min），二次确认 13:36（task=973）。本次 run 配置见 §3.2（--max-tasks 64 --max-runs-per-task 16 --max-concurrent-closes 32，dockerd --ulimit nofile=65536:524288）。

• 症状：tail -F training_8b.log 在某些 task 命中 batch 时抓到 7 条 env.reset failed (HTTPStatusError): Server error '500 Internal Server Error' for url '/reset'，集中在某个 task_id 的 8 个并发 lease 里。

• pool 端真实错误（docker logs openclaw_pool_server 抓到）：

  Error response from daemon: Conflict. The container name "/tb__<task>__<helper>"
  is already in use by container "<sha>..."
  

• 根因：

  1. terminal_bench/handlers/trial_handler.py:266 的 docker_image_name_prefix = f"tb__{self.task_id}".replace(".", "-") —— 只用 task_id，不带 trial_name 里的 uid；
  2. 部分 task 的 docker-compose.yaml 直接把 helper service 的 container_name 绑定到这个共享 prefix（典型形如 container_name: ${T_BENCH_TASK_DOCKER_NAME_PREFIX}__<helper>）；
  3. GRPO n-samples-per-prompt=8 同 task 并发 8 个 lease → 第 1 个建好 tb__<task>__<helper>，剩下 7 个全 dockerd Conflict 500。

• 影响范围（dataset 全量 grep）：

  grep -lE 'container_name:.*DOCKER_NAME_PREFIX' dataset/seta_env/*/docker-compose.yaml

  整个 dataset 1376 个 task 中共 5 个命中此 anti-pattern：

  task_id	helper service	docker-compose 行
  890	dev-server	container_name: ${T_BENCH_TASK_DOCKER_NAME_PREFIX}__dev-server
  892	remote-server	container_name: ${T_BENCH_TASK_DOCKER_NAME_PREFIX}__remote-server
  973	worker	container_name: ${T_BENCH_TASK_DOCKER_NAME_PREFIX}__worker
  1133	web-server	container_name: ${T_BENCH_TASK_DOCKER_NAME_PREFIX}__web-server
  1198	bastion	container_name: ${T_BENCH_TASK_DOCKER_NAME_PREFIX}__bastion

  其他 1371 个 task 的 client 服务都用 T_BENCH_TASK_DOCKER_CLIENT_CONTAINER_NAME（lease-unique，来自 trial_name.replace(".","-")），不冲突。

• 量化：

  • dataset 占比：5 / 1376 = 0.36%
  • 每 rollout 命中概率：rollout-batch-size=16 prompt → 命中至少一个 buggy task 的概率 ≈ 1 − (1371/1376)^16 ≈ 5.7%；命中时该 group 8 sample 中 7 fail
  • 每 rollout 期望 fail sample 数：(16 × 5/1376) × 7 ≈ 0.4 sample
  • pool 层 reset 失败率（实测，run-3 启动 +35 min 滚动窗口）：132 个 500 / 759 个总 reset = 17.4% pool-level（因为 trainer 端有 retry，单次 trainer-visible fail 对应 ~14 个 pool-level 500）
  • trainer 层 sample 失败率：9 sample 标记 FAILED / 总 ~256 sample = 3.5% trainer-visible
  • 训练影响：fail 的 sample 进入 GRPO 同 group，被 _drop_constant_reward_groups（slime/ray/rollout.py:400-451）整组砍掉，不进梯度。对 grad_norm/kl_loss/response_len 全部不敏感。non_trainable_ratio 顶多 +5.5%（命中时），远低于 0.85 stop threshold。
  • 实测 run-3 step 1 (grad_norm=0.7749, kl_loss=0.000557) 完全健康，trainer 通过 generate.py:181 → Marking sample FAILED 路径正确吸收，无任何下游 exception。

• 和 issue Qwen3-8B terminal-rl run (45h, ~1100 steps): peak 0.45 acc → mode collapse #2 末段 reset 500 的本质区别：

  项	issue Qwen3-8B terminal-rl run (45h, ~1100 steps): peak 0.45 acc → mode collapse #2 末段 reset 500	本条（5 个 task） reset 500
  dockerd 报错类型	address pools fully subnetted / Too many open files	Conflict. The container name ... already in use
  影响范围	全局，所有 task 受影响	仅 5 个 task（0.36%）
  触发频率	持续累积，越跑越严重	仅相关 task 命中 batch 时（~5.7%/rollout）
  是否 pool 系统级问题	是（资源/配置耗尽）	否（dataset fixture bug）
  已修 / 未修	已通过 §3 配置修复	dataset 自身 bug，本节记录

• 当前处置（run-3 持续期）：暂不修。依靠 _drop_constant_reward_groups 自然吸收，对训练 0 影响。仅在本 issue 记录在案，便于后续如需要彻底拔刺时一次 patch 5 个 task。

• 可选 patch（一行修 × 5 个 task）：对每个 buggy task，把 helper service 那一行 container_name: 删掉即可。以 task 892 为例：

   remote-server:
     image: ${T_BENCH_TASK_DOCKER_NAME_PREFIX}__remote-server
  -    container_name: ${T_BENCH_TASK_DOCKER_NAME_PREFIX}__remote-server
     hostname: remote-server

  其他 4 个同理（删自己的 container_name 行）。docker compose 会自动按 <project>_<helper>_1 命名（project 名是 lease-unique 的 <task>-<uid>-<group>-<sample>），冲突消失。hostname: 与 networks: 保持原样，task 内部 ssh <helper> / curl <helper> 都通过网络 alias 解析，不依赖 container_name —— 全部 5 个 task 的 solution.sh / task.yaml / tests/ grep 验证均只用 hostname 形式，零依赖 container_name。pool 不需要重启，下一次 reset 自动读取新 compose。

• 副作用观察：本类问题在 run-3 启动 +35 min 窗口内导致 pool /status 的 pending_closes 攀到 91（vs 健康水位 < 5）。close 队列的 backlog 来源是：每次 Conflict 500 → trainer mark FAILED → close lease → close 进队，conflict 频次乘以 close 单次耗时 (~1-3 s) 推高队列。目前还在 --max-concurrent-closes 32 × 3 周期 余量内，但若同一 rollout 命中 ≥ 2 个 buggy task 可能会逼近上限——这是后续如果 §6 建议 实验记录：terminal-rl Qwen3-8B run-3 (60h, 565 step, wandb msp60ius) — accuracy 0.32→0.52，无 mode-collapse + 6 类 dataset 卡顿 #4（提高默认值）落地的另一个理由。

7.2 dockerd 瞬时 image 一致性错误（极罕见，自愈）

• 发现于：run-3 wandb msp60ius，13:36 ± 1 min（与 §7.1 同一时间窗），整个 run-3 启动 +35 min 内出现 1 次。
• 症状：docker logs openclaw_pool_server 抓到一条：

  STDERR: unable to get image 'tb__968__client': consistency error: data changed
  during operation, retry
  

  配套一个 POST /reset HTTP/1.1 500 Internal Server Error，对应 lease 被 trainer mark FAILED。
• 根因：dockerd 内部状态：在并发 compose up -d 同时读 / 写 image metadata 时偶发的 CAS retry race（buildkit + image store 锁冲突）。和我们这套 pool 的代码、dataset 配置都无关。
• 影响量化：
  • 触发频率：1 / 759 reset = 0.13%（35 min 滚动窗口）
  • 训练影响：sample 级 FAILED，与 §7.1 同款被 _drop_constant_reward_groups 吸收，0 梯度影响
• 当前处置：不修。dockerd 自带 retry 文案就明示 ..., retry，下次 reset 重试自动通过；这是 docker 上游级别的偶发，运行时不可预测，没必要为单次 0.13% 的事件做任何事。
• 观察建议：若同一 run 中本类错误 > 1%/小时，再考虑升级 dockerd 或加 explicit retry layer。本次 run-3 是 0.13%，远低于阈值。

7.3 dataset Dockerfile COPY 引用了缺失的本地文件 → buildkit checksum 失败

• 发现于：run-3 wandb msp60ius，14:08（启动 +62 min）发现 task=999；扫全 dataset 后追加 task=25。

• 症状：tail -F training_8b.log 抓到 8 条 env.reset failed (HTTPStatusError): Server error '500 Internal Server Error' for url '/reset'，集中在某个 task 的全部 8 个并发 lease 上（与 §7.1 同款 trainer-side 表现，但根因不同）。

• pool 端真实错误（docker logs openclaw_pool_server 抓到）：

  STDERR: failed to solve: failed to compute cache key: failed to calculate
  checksum of ref <...>::<...>: "/mock_journalctl.log": not found
  

  buildkit 在 docker compose build 阶段尝试为 COPY 指令算 cache key，但本地文件不存在 → 整个 build 失败 → reset 500。

• 根因：dataset 的 Dockerfile 里有 COPY <file> <target>，但 <file> 没被打包进 dataset/seta_env/<task>/ 目录。

• 影响范围（dataset 全量扫描）：

  for d in dataset/seta_env/*/; do
    df=$d/Dockerfile; [ ! -f "$df" ] && continue
    awk '/^COPY/ && !/<</' "$df" | while read line; do
      for ref in $(echo "$line" | awk '{for(i=2;i<NF;i++) print $i}' \
                   | grep -v '^--' | grep -v '^[/$]'); do
        [ ! -e "$d$ref" ] && echo "task=$(basename $d) MISS: $ref"
      done
    done
  done

  整个 dataset 1376 个 task，共 2 个有缺失文件：

  task_id	Dockerfile COPY 行	缺失文件
  25	COPY sample.log /...	sample.log
  999	COPY mock_dmesg.log /var/log/mock_dmesg.log	mock_dmesg.log
  999	COPY mock_journalctl.log /var/log/mock_journalctl.log	mock_journalctl.log

• 量化：

  • dataset 占比：2 / 1376 = 0.15%
  • 每 rollout 命中概率：rollout-batch-size=16 prompt → 命中至少一个 buggy task ≈ 1 − (1374/1376)^16 ≈ 2.3%
  • 每 rollout 期望 fail sample 数：(16 × 2/1376) × 8 ≈ 0.18 sample
  • 训练影响：与 §7.1 同款被 _drop_constant_reward_groups 整组砍掉，不进梯度，对 grad_norm/kl_loss/response_len 全部不敏感
  • 实测 run-3 step 7 (grad_norm=0.948, kl_loss=0.012) 完全健康，trainer 通过 generate.py:181 → Marking sample FAILED 路径正确吸收

• 和 §7.1 / §7.2 的区别：

  项	§7.1 Conflict	§7.2 dockerd 一致性	§7.3 缺失 COPY 文件
  错误层	dockerd container manager	dockerd image store	buildkit
  错误文案	Conflict. The container name ... already in use	consistency error: data changed during operation	failed to compute cache key: ...: not found
  dataset 还是上游 bug	dataset compose 配置	dockerd 自身偶发	dataset 文件缺失
  是否任务侧能修	是（删 container_name 行）	否	是（补回缺失文件）
  命中 task 数	5	n/a（瞬时）	2

• 当前处置（run-3 持续期）：暂不修。同款依靠 _drop_constant_reward_groups 自然吸收。

• 可选 patch（需要 dataset 上游补回文件）：

  • task 25：补回 sample.log（看 task.yaml 描述给出合适内容；或者从原 terminal-bench 上游 dataset repo 拉一份 reference）
  • task 999：补回 mock_dmesg.log 和 mock_journalctl.log（这两个看名字是 mock 数据，参考同 task 已有的 mock_lspci_data.txt 风格手写一份）
  • 修完后 pool 不需要重启，下次 docker compose build 会自动 pick up 新文件

---

cc @<repo maintainers>，欢迎反馈（特别是 §6 的 4 条改动是否合并主线）。

[HansBug]

§7.8 现场记录 — run-3 训练侧 stuck 事件：单 sample 在 Turn 1 输出 66 个重复 nmap tool calls，导致 agent_runner 顺序执行 3.5+ 小时

触发于 issue #3 涉及的 wandb run msp60ius（run-3 8B）。这是 §7.8 候选——slime/agent_runner 缺 turn 级 wall-clock timeout 的实际 case，与之前 §7.1–§7.7 的 dataset / pool 侧 bug 性质不同，是 训练侧 (slime + RolloutManager + agent_runner) 的健壮性问题。

---

TL;DR

run-3 在第 ~17.5h 时整训练 stuck 3 小时 45 分钟——Megatron train_wait 自 07:45:25 → ~11:30 自然解除。深查后发现：

• 卡的不是 pool / dockerd / SGLang；
• 卡的是 slime 的 agent_runner 在顺序执行 model 输出的 66 个 tool call；
• 而 model 这次 Turn 1 输出 66 个 tool calls 中 63 个是完全相同的同一条 nmap 命令——典型的 LLM 退化输出（loop 模式）；
• 每个 shell_exec 名义 timeout=300s，单 nmap -sV 在容器内 5-10 min/次，理论总时长 ~5 h；
• agent_runner 没有 turn 级 wall-clock timeout——它会老老实实把 66 个全部跑完才 yield；
• GRPO 同步训练任何一个 sample stuck 都会卡住整个 batch，于是连锁卡 ckpt + train step + wandb commit。

---

1. Stuck 事件时间线

时间 (UTC)	事件
07:40:02	RolloutManager allocate sample_idx=15184 (task=786 uid=40e612a3 group=1898 lease=run-8a1d0086ff3e4c86)
07:41:28	Remote env reset complete. Starting terminal rollout.
07:42:19	Turn 1: executing 66 tool call(s) — agent_runner 开始顺序执行
07:45:25	Megatron actor 进入 Timer train_wait start（等本批 rollout 完成）
08:00–08:05	group=1898 其他 7/8 个 sample 全部 Evaluation completed（reward=0.0）
08:05 起	pool active_runs=1、容器 786-40e612a3-1898-15184 持续 alive、SGLang 仅心跳
11:13	容器内 ps -ef 抓到 第 N 个 nmap 进程刚启动（启动 17+ min 仍在跑）
~11:30	训练 自然解锁 —— pool active 切换到 10 个新 task、wandb _step 恢复推进
11:34	确认 stuck 解除：n_train=216 不变（仍在 rollout 阶段），但 sample 15184 lease 已 GONE

stuck 持续 3 小时 45 分钟，期间：

• train_wait 阻塞自 07:45:25 → 11:30+
• ckpt iter_111（spike 后那个）3 h 完全不推进
• wandb _step 在 687 完全冻结
• n_train events 在 216 完全冻结

---

2. Task 配置（task=786）

dataset/seta_env/786/task.yaml 的关键段落：

instruction: |-
  You are a systems administrator performing a network audit of a simulated corporate LAN.
  ...
  Your tasks are:
  1. Install nmap (it is not pre-installed) and use it to discover all active hosts on the
     192.168.50.0/24 subnet. ...
  2. For each discovered active host IP, perform a service/version scan to identify what
     services are running and on which ports.
  3. Produce a structured inventory report as a JSON file at /home/user/network_audit_report.json.
  4. Create a summary file at /home/user/network_summary.txt ...

max_agent_timeout_sec: 300.0   ← terminal-bench 框架字段，slime 未使用
max_test_timeout_sec: 120.0

dataset/seta_env/786/docker-compose.yaml 内含 8 个 socat listener，模拟 192.168.50.0/24 上的 8 个 host × 多种服务。task 本身没问题——8 个 sample 中 7 个都正常 finish 在 10 turn 内。

3. group=1898 8 个 sample 的运气分布

sample_idx=15184  Turn 1: 66 tool calls   ← 卡 3.5h
sample_idx=15185  Eval completed   08:00:47  reward=0.000  ✅ (10 turn timeout)
sample_idx=15186  Eval completed   07:59:35  reward=0.000  ✅
sample_idx=15187  Eval completed   07:58:07  reward=0.000  ✅
sample_idx=15188  Eval completed   08:05:06  reward=0.000  ✅
sample_idx=15189  Eval completed   07:55:18  reward=0.000  ✅
sample_idx=15190  Eval completed   07:50:42  reward=0.000  ✅
sample_idx=15191  Eval completed   07:59:18  reward=0.000  ✅

7/8 sample 正常 turn 10 触发 Max iterations (10) reached（默认 --num-steps-per-rollout=2 配 GRPO n-samples-per-prompt=8）后 evaluate=0 完成。

只有 sample_idx=15184 在 Turn 1 就触发 66 个 tool calls 退化——模型这一个 sample 被生成的 tool_calls list 大幅超过正常水平（其他 sample 每 turn 1 个 tool call）。

4. 模型输出的 66 个 tool calls — 退化模式

training_8b.log line 615898 是一个 21,609 字符的超长行，序列化了全部 66 个 ToolCallRequest。逐项解析后：

#	tool_name	command (truncated)	timeout
1	shell_exec	apt-get update && apt-get install -y nmap	300s
2	shell_exec	nmap -sn 192.168.50.0/24	300s
3	shell_exec	nmap -sV 192.168.50.0/24	300s
4–66	shell_exec ×63	nmap -sV 192.168.50.0/24 | grep -Eo '...' | sort -n | uniq > /home/user/network_audit_report_ports.txt（63 次完全相同）	300s ×63

也就是说：

• Tool call 1：合理（装 nmap）
• Tool call 2-3：合理（host discovery + version scan）
• Tool call 4-66：完全退化——同一行复杂的 nmap pipeline 重复 63 次

每条 nmap -sV 在 256-host /24 网段 + multi-port version detection ≈ 5-10 min/次。即使每条只跑 5 min：

3 × 5 min  +  63 × 5 min  =  330 min  =  5.5 hour

实测跑到 3 h 45 min 自愈（推断是 agent_runner 在某个 nmap 完成后触发了 abort 路径，但精确机制未落实）。

5. 完整 stuck chain（修正后的层次诊断）

层	状态	时间戳
L1 SGLang generate	正常（07:42:19 已成功生成 66 tool calls 的 token、return）	已完成
L2 agent_runner	stuck — 在 await pool.exec_tool(...) 顺序执行 66 个 tool call，每个 nmap 都跑完才进下一个；slime 的 agent_runner 没有 turn 级总时长 cap	卡 07:42
L3 generate.py	等 agent_runner 完成才能 evaluate → 永远不到 evaluate	卡
L4 RolloutManager	等 group=1898 8/8 sample 都完成才能 commit batch → 7/8 已等到、1/8 在 L2 卡死	卡
L5 Megatron train_actor	Timer train_wait start 等 RolloutManager 信号	自 07:45:25
L6 wandb / ckpt	无新 train_step → 无 commit、无 ckpt	iter_111 不动

容器内（爆破前 11:13 抓到的 ps 快照）：

PID 46455  bash -c 'nmap -sV 192.168.50.0/24 | grep -Eo (...) | sort -n | uniq > .../report.txt'
PID 46461  nmap -sV 192.168.50.0/24

容器其他进程是 setup_network.sh 启的 8 个 socat listener + sleep infinity ——容器内没有死循环，只是 nmap 一个接一个慢慢跑。

6. 各层 timeout 配置 vs 实际效果（Why no rescue）

层	配置	是否生效
ToolCallRequest.timeout (model 自填)	300s 每个	✅ 单条 shell_exec 内部生效（不会无限挂在一条）
pool /exec_tool block=True	tmux 等	✅ 单次
task_timeouts.eval (TaskTimeouts.eval)	600s	仅 evaluate 阶段；rollout 阶段无效
task.yaml max_agent_timeout_sec	300s	❌ terminal-bench 字段，slime/agent_runner 未读
agent_runner.max_iterations	10	❌ 是 Turn 级（>10 turn → break），不是 tool-call 级。Turn 1 永远不会触发
pool reaper run_idle_ttl	600s	❌ last_used_ts 在每次 exec_tool 调用时被刷新，66 个 nmap 一直 active 所以 reaper 不会 trigger
ckpt save_interval	8 iters	❌ 没 train_step 推进就没 ckpt

结论：在单 turn 内执行多 tool call 时，没有任何一层 timeout 能 cap turn 总时长。

7. RolloutManager / 其他 sample 同时段表现（旁证：训练侧整体未死）

stuck 期间 RolloutManager 仍在正常处理其他 sample：

07:42:19   sample_idx=15184 group=1898  Turn 1: 66 tool call(s)         ← stuck 起点
07:42:19   sample_idx=15179 group=1897  Turn 1: 130 tool call(s)        ← 注意：另一个 sample 也输出了 130 tool calls！
07:42:19   sample_idx=15145 group=1893  Max iterations (10) reached     ← 正常完成
07:42:19   sample_idx=15138 group=1892  Turn 10: 1 tool call(s)         ← 正常
07:42:19   sample_idx=15225 group=1903  Rollout finished                ← 正常
... 大量 sample 在跑

注意 sample_idx=15179 同时段也输出了 130 个 tool calls——可能是同一个模型退化模式的另一表现，但因为它的 task 和 sample_idx=15184 不同（task=903），命令组成不同，跑得快或慢未知。

这说明 退化输出不是孤立现象——这一批训练在第 ~17h 时模型大概率已经偶尔产出 50+ tool call 的 turn，是新出现的失败模式。

8. 自愈机制（部分推断）

11:30 stuck 解除时容器 786-40e612a3-1898-15184 已经 GONE，pool active runs 切到了新 batch 的 10 个 task。具体解锁机制未完全 root cause，可能是其中之一：

1. agent_runner 跑完 66 个 nmap（最 plausible，时长 3h45m 接近预测下限） → tool result 列表返回给模型 → 模型在 Turn 2 因 prompt 超长触发 truncation/return → rollout finish
2. 某个 nmap 偶发 fail（exit code != 0）触发 agent_runner 的 except path → mark sample FAILED
3. pool reaper 终于触发（3.5h 内某 watchdog 路径生效）→ close run slot → exec_tool 在该 lease 上的下一次调用 fail → agent_runner 收 exception → sample FAILED

定位精确机制需要再加 instrumentation。但对训练影响：单 sample FAILED → 该 group 其他 7 个 sample 都已 reward=0 → _drop_constant_reward_groups 把整 group 砍掉（zero variance）→ batch 仅丢 1 group → train_step 用其余继续。损失轻微。

9. 实际处置（全过程无人工干预）

run-3 babysit 期间，cron babysitter 监控到 stuck 后给出过 3 个候选：

• A：sudo docker rm -f 786-40e612a3-1898-15184 —— 杀容器触发 in-flight exec_tool 抛 exception，预计 5-30s 解锁 trainer，0 ckpt 损失
• B：pkill ... ; ray stop --force —— EARLY-STOP，从 iter_111 resume，损失 ~30 min 训练
• C：等自愈 —— 不确定多久

最终用户选 C，等到 11:30 自然解除。教训：

• 单次 stuck 平均 ~3-4h（与本次和 01:08 那次类似 case 一致）
• 但不能依赖自愈——下次可能 stuck 5h+ 或永远（没真正的 wall-clock cap）
• A 是低风险高确定性恢复路径，但需要人工执行（pool 没自动检测）

10. 修复建议（按优先级）

1. agent_runner 添加 turn 级 wall-clock timeout（最重要）

   • 默认值参考 task.yaml max_agent_timeout_sec（多数 task 是 300s）或 hard cap（如 5min）
   • 触发后整 turn 视为 fail，其余 tool calls 跳过，sample 走 FAILED 路径
   • 1 行 asyncio.wait_for(turn_execution, timeout=300) 即可

2. tool call 去重 / 限流

   • 检测连续相同 tool call（如 same command 字符串）
   • 超过阈值（例如同 turn 内同 command 出现 ≥ 3 次）即视为退化输出，提前 break turn
   • 防御性应对模型退化输出

3. 限制单 turn tool calls 数量上限

   • 当前没有 max_tool_calls_per_turn cap
   • 建议默认 8-16，超出截断（discard 后续）+ warning

4. pool reaper 真正按 wall-clock 工作

   • 当前 last_used_ts 在每次 exec_tool 调用都刷新，所以 idle reaper 永不 trigger
   • 改为：lease 有 created_ts，若 now - created_ts > max_lease_lifetime（例如 30 min）强制 close（无论 active 状态）
   • 这是 pool 端的 last-resort safety net

5. monitor 自动化：在 babysit 工具中检测到 wandb _step 静止 > 30 min + train_wait 启动 > 30 min 时，自动执行 A（仅在用户预先授权下）

11. 这次 cost

• 训练损失：~3 h 45 min × ~7 train events/h ≈ 26 个 train events 没产出
• ckpt：iter_111 仍保留，stuck 期间什么都没存
• 模型权重：未受影响（trainer 没 crash，weights 没 resume，是 idle）
• pool 状态：未受影响（stuck lease 自愈后正常释放）

run-3 累计已完成 220+ train events / 12 ckpts（iter_7 → iter_111）+ 后续仍在跑——本次 stuck 折损约 12% 总训练时间，可接受。

---

关联：

• run wandb msp60ius
• pool 配置 issue env-pool 完整记录：架构 / 6 个踩坑 / 持久化配置 / 系统化验证脚本（issue #1/#2 末段退化的环境侧根因） #3 §3.2（--max-tasks 64 --max-runs-per-task 16 --max-concurrent-closes 32）
• §7.8 候选项之前已经在 §7.5 task 1133 reset 500 + §7.6 task 1045 host port 时归档，但本次是首次 fully reproduce + root cause 完成
• 同类 stuck 在 run-3 的 01:08 也发生过一次（task=210 secure_wipe.sh 死循环），自愈在 35 min；本次 task=786 自愈耗时 3h45m，差异主要是 task=210 容器内有 CPU-bound 死循环更早被某 timeout cap，task=786 顺序 nmap 没单条挂死所以 cap 不到

[HansBug]

env-pool 60h+ 真实运行验证：6 类卡顿 pattern + 数据集惯犯黑名单

接 run-3 实验主帖 — 这次拿 --max-tasks 64 --max-runs-per-task 16 --max-concurrent-closes 32（1024 lease pool）跑了 60h12m / 565 step / 283 rollout，全程 0 fatal pool 错误（无 Too many open|address pools|429），但真正暴露了 dataset 侧 6 类卡顿 pattern，本次 comment 把每类带例子完整记下来，作为 "在容器/lease/资源 3 层都没出问题的前提下，单容器内 sample 仍可能拖到训练空转 5h+" 的存档。

---

0. 本次 pool 启动配置（容器命令完整）

docker create:
  python -m terminal-rl.remote.pool_server
    --host 0.0.0.0 --port 18081
    --max-tasks 64
    --max-runs-per-task 16
    --max-concurrent-closes 32
    --output-root /nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/build_outputs
created: 2026-04-26T12:48:25Z
uptime  : 60h+ (无重启)

每个 GRPO rollout = rollout_batch_size=16 prompt × n_samples_per_prompt=8 = 128 lease 同时活动，pool 容量 1024 / 实际峰值 128 = 12.5% 利用（远未到瓶颈）。issue #3 主帖里调过的几个参数（run_idle_ttl=600s、max_concurrent_closes=32）这一轮都正常生效。

---

1. 60h+ 运行的 pool 错误统计

整条 training log 全文 grep 得到（log 文件 457 MB）：

pattern	全程总数	平均 / 小时	性质
502 Bad Gateway (router 返回)	27	0.45	router 偶发瞬断，agent_runner 已 retry，不致命
500 Internal Server Error (evaluate)	3,104	51.7	任务侧 pytest 失败，slime 已 graceful 处理为 reward=0
Too many open files	0	0	✅
address pools have been fully subnetted	0	0	✅
429 Too Many Requests	0	0	✅
Marking sample FAILED after evaluation error	711	11.8	slime 兜底（500/502 转 reward=0），不影响训练

→ 所有"致命"指标全为 0，issue #3 主帖里担心的 fd 耗尽 / Docker subnet 耗尽 / 限流，这次 60h 实测均未触发。pool 整体是稳定的。

真正影响训练吞吐的不是 pool 资源，而是 下面的"dataset 惯犯卡顿"。

---

1.X 评估失败深度归因 — evaluate 500 × 3,104 / Marking FAILED × 711 到底是什么 ⚠️

把全 log "error":"..." 字段全部拉出来分类（grep 然后 sort | uniq -c），3,104 个 evaluate 500 不是同一种错误，而是 5 类完全不同的根因，每类的"是不是 env bug"答案不一样：

Cat	错误指纹	计数	性质	模型 vs 环境责任
A	asciinema is not installed in the container	145	pool 镜像 / 任务 fixture 缺包	环境 bug 100%
B	docker compose ... build returned non-zero exit status 17 (task 999/305/25)	216	task fixture 的 Dockerfile 构建失败	task fixture bug 100%
C	Failed to parse test output for task=X with parser=PytestParser: No short test summary info found	310	pytest 没产生 short summary 段	task 设计 + 模型协同 bug
D	Evaluation tests timed out for task=X after 240.0s/480.0s	144	pytest 超过 task.yaml 配的 max_test_timeout_sec	模型行为 100%
E	Worker unreachable: TimeoutError / ClientOSError: Connection reset by peer	23	HTTP 短暂连接异常	pool transport 偶发
	合计有名错误	838

为什么 838 < 3104？因为同一个 sample 的 evaluate 失败会被 slime 重试 1-3 次，每次都进 500 计数。838 个去重后基本对应 711 个 Marking FAILED（即 sample reward=0），剩下的几百次 500 是同一 sample 的 retry。

下面把 5 类挨个展开。

Cat A — asciinema is not installed (145×) — pool image bug，可直接修复

真实日志样本：

{"ok": false, "error": "Recording is enabled but asciinema is not installed in the container.
                        Please install asciinema in the container to run Terminal-Bench."}

根因：terminal-bench 默认在评估时启 asciinema 录屏（disable_asciinema: false 是 task.yaml 的默认值）。pool image 里没有装 asciinema，所以一旦 task 走录屏分支就崩。

为什么不是 100% 重现而是 145 次：相关 task 的 disable_asciinema 字段不一致，部分 task.yaml 写了 disable_asciinema: false 但 image 里又能 fallback 到 --no-asciinema，部分则 hard fail。

修复可行性 ✅ HIGH：

• 短期（<5min）: pool image 加一行 apt-get install -y asciinema，重新 build pool 镜像即可
• 中期: 在 terminal_env.py 评估前自动 pip install asciinema || apt install asciinema || disable recording
• 长期: 给 seta_env_convert/ 转换脚本加默认 disable_asciinema: true（既然 RL 训练根本不需要回放录屏）

副作用: 几乎为零。装 asciinema 仅 ~2 MB。disable_asciinema=true 不影响测评结果，只是少录个 cast 文件。

---

Cat B — docker compose build exit 17 (216×) — task fixture Dockerfile 失效

真实日志样本：

{"ok":false,"error":"Command '['docker', 'compose', '-p', 'build_run', '-f',
  '/nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/dataset/seta_env/999/docker-compose.yaml',
  'build']' returned non-zero exit status 17."}

docker compose build exit 17 = 构建过程中 RUN 失败（apt 包消失 / pip mirror 503 / 远端 git repo 删了）。全部集中在 3 个 task：

task	失败次数	评测成功次数	失败率
999	72	0	100%
305	72	0	100%
25	72	0	100%

3 个 task 全部 0 成功 — 这 3 个 task 的 Dockerfile 在我们这台机器上就是构建不起来。

根因（猜测，需要单独验证一下其中 1 个）：

• 上游 base image (ubuntu:20.04) 的 apt 源失效 / 某个 deb 包被 archive
• RUN pip install ... 拉的版本被 yanked
• 任务 fixture 引用的外部资源（git clone / wget URL）已下线

修复可行性 ✅ HIGH：

• 短期（5min）: dataset 黑名单这 3 个 task（一行配置）
• 中期（30min）: 手动逐个 docker build 看具体哪行 RUN 失败，提交 PR 给 seta-env 上游修 Dockerfile
• 长期: convert 脚本在 build 时预 sanity-check，把 build 失败的 task 自动剔出训练集

副作用: 黑名单零副作用（1376 → 1373 task，<0.3%）。

---

Cat C — pytest parser: No short test summary (310×) — task fixture 测试输出不规范

真实日志样本：

[task=684 uid=2c97cb55] env.evaluate failed:
  {"ok": false, "error": "Failed to parse test output for task=684 with parser=PytestParser:
    No short test summary info found in the provided content."}

terminal-bench 的 PytestParser 期望从 pytest stdout 里找 === short test summary info === 段。没找到 = 解析器把整个输出标记为格式错误，返回 500。

全程 0 成功 / 100% 失败的 task（最严重）：

task	FAILED 次数	Eval done	推断根因
684	32	0	run-tests.sh 用 uv 启 pytest 但未 -rA/未 emit summary
345	32	0	同上
553	24	0	同上

部分但不是 100% 失败的 task（task 有时能过有时不能）：

task	FAILED	Eval done	失败率
962	30	2	94%
916	23	1	96%

task=684 实际 run-tests.sh 内容：

# Install fuser for lock file checking (part of psmisc)
apt-get update 2>/dev/null || true
apt-get install -y psmisc 2>/dev/null || true
...
# Install uv
curl -LsSf https://astral.sh/uv/0.7.13/install.sh | sh
source $HOME/.local/bin/env
# (continues with pytest invocation)

根因：pytest 启动前的 apt-get/curl 步骤如果在某些 sample 走的容器里失败（比如网络瞬断、apt repo 锁），整个 run-tests.sh 没到 pytest 阶段就退了，stdout 没有 short summary，parser 报错。

这部分也包含模型行为责任：模型如果把容器内的 psmisc/uv/Python 环境搞坏（比如 rm -rf /usr 之类，task 256/890/etc. 这种 dangerous task），后续 pytest 自然崩。但 task=684/345/553 的 0% 通过率指向 fixture 本身设计就脆。

修复可行性 🟡 MEDIUM：

• 短期（<5min）: dataset 黑名单 100% 失败的 3-5 个 task
• 中期（1-2h）: 改 terminal-bench 的 PytestParser 让它对"非 pytest 输出"返回 reward=0（已 graceful），而不是让 evaluate 抛 500
• 长期: convert 脚本预跑 1 次 solution.sh + run-tests.sh，验证 pytest summary 存在，否则剔除 task

副作用: 中期改 parser 几乎零副作用（只是把 500 转成 reward=0，slime 已经在做这个 fallback）。

---

Cat D — Evaluation tests timed out (144×) — 模型写出无限循环，超过 task 自身的 max_test_timeout_sec

真实日志样本：

{"ok":false,"error":"Evaluation tests timed out for task=916 after 480.0s"}

来自 task.yaml 里的 max_test_timeout_sec（默认 120s，部分任务定 240s 或 480s）。超时机制本身没问题，超时后 pool 抛 500，slime 兜底 reward=0。

Top 5 timeout 任务：

task	timeout 次数	timeout 阈值	备注
916	23	480s	模型可能写了 while true; do ...; done 类无限循环
1264	11	240s
282	8	240s
324	7	240s
768	6	480s
46	6	480s
210	6	480s	本次 §2.6 secure_wipe 死循环 task，issue #3 §7.6 已记录

根因：模型行为，不是 env bug。模型在某些 task 上写出会死循环 / 等待用户输入 / 阻塞 IO 的 solution。pytest 测试用例本身有 subprocess.run(timeout=...) 但部分老 task 的 test_outputs.py 没设 timeout 参数，导致 pytest 自身 hang。

修复可行性 🟡 MEDIUM：

• 短期: 把 6 次以上 timeout 的 task 列入黑名单（task=210/916/1264/282/324/768/46）
• 中期: 在 terminal-bench 的 PytestParser 评估前给所有 subprocess.run(...) 注入默认 timeout=30
• 长期: 用更小的 max_test_timeout_sec（默认 120s 改 60s），逼 task 设计者写更快的测试

副作用: 短期黑名单零侵入。中期改 parser 可能影响一些"故意要等慢"的 task（比如 task=90 swap monitor 自身要求 5min 监控）— 需要 case-by-case。

---

Cat E — Worker unreachable: TimeoutError / Connection reset by peer (23×) — pool transport 偶发

真实日志样本：

[task=856 sample 35353] http_utils.py:218 - Error: Server error '502 Bad Gateway' for url
  'http://127.0.0.1:18080/exec_tool'
For more info: ..., retrying... (attempt 1/3, response=
  {"ok":false,"error":"Worker unreachable: TimeoutError",
   "worker_idx":0, "worker_url":"http://127.0.0.1:18081",
   "path":"/exec_tool", "lease_id":"0:run-7ff26257d9c54a4f"})
# retry 立即失败：
http_utils.py:218 - Error: Server error '500 Internal Server Error'
For more info: ..., retrying... (attempt 3/3, response=
  {"ok":false,"error":"'Unknown run_lease_id: run-7ff26257d9c54a4f'"})
Max retries (3) reached, failing...

根因：

1. router (port 18080) 向 worker pool (port 18081) 发 HTTP 请求，pool 未及时响应 → router 返回 502
2. router 重试时，pool 已经把 lease GC 掉了 → 返回 Unknown run_lease_id (500)
3. 重试 3 次都失败 → 整个 sample 标记 FAILED

为什么"未及时响应"：通常发生在 pool 同时处理大量 docker compose down 时（max_concurrent_closes=32 仍可能拥塞），单 HTTP 调用排队超过 router 的默认 timeout（30s）。

修复可行性 🟡 MEDIUM：

• 短期: 把 router 的 HTTP 客户端 timeout 从 30s 调到 90s（issue env-pool 完整记录：架构 / 6 个踩坑 / 持久化配置 / 系统化验证脚本（issue #1/#2 末段退化的环境侧根因） #3 主帖讨论过类似 patch）
• 中期: pool server 加请求队列 backpressure，避免短期 burst 拖死 worker thread
• 长期: 把 router 与 pool 合并为单进程（去掉 18080→18081 双层），减少一次 HTTP hop

副作用: 短期 timeout 调长几乎零副作用（只是某些慢请求会等更久），中期 backpressure 需谨慎不要让 GRPO 回压到 actor 端导致 train_wait 飙升。

---

1.X 综合判定

Cat	计数	责任归属	短期可修	推荐优先级
A asciinema	145	环境 100%	✅ 1 行 Dockerfile + rebuild	P0
B build exit 17	216	task fixture 100%	✅ 黑名单 task 999/305/25	P0
C pytest parser	310	task fixture + 模型协同	✅ 黑名单 task 684/345/553，改 parser fallback	P1
D timeout	144	模型 100%	✅ 黑名单 + parser 注入 timeout	P2
E worker unreachable	23	pool 偶发	🟡 router timeout 调长	P3

结论：

• 这 711 个 Marking sample FAILED 不是单一 bug，是 5 类不同失败模式的混合
• Cat A + Cat B = 361 次失败可以纯通过 patch pool image / dataset 黑名单消除（占 51%），零模型/算法侧改动
• Cat C 的 100% 失败 task 黑名单 + parser graceful fallback 还能再消除 ~80%
• 最终留给 slime graceful 兜底的应该 < 20%

最关键的 actionable：

# Cat A:
docker exec -u root <pool_image_build_dir> apt-get install -y asciinema
# OR add to Dockerfile.pool:
RUN apt-get install -y asciinema

# Cat B + Cat C 黑名单:
# terminal-rl/data_utils/convert_task_to_dataset.py
DATASET_BLACKLIST = {
    # Cat B: docker build exit 17
    '999', '305', '25',
    # Cat C: pytest parser 100% fail
    '684', '345', '553', '962', '916',
    # Cat D: timeout 高频 (>5)
    '210', '916', '1264', '282', '324', '768', '46',
    # 已知 stuck pattern (本帖 §2)
    '786', '96', '90', '456', '856',
}
# 实际上 Cat C 的 916 与 Cat D 重复，去重后 ~14 个 task
# 1376 - 14 = 1362 task，影响 < 1%

应用这套清单后，预估 evaluate 500 失败率从 3,104/47,544 ≈ 6.5% 压到 < 1.5%。

---

2. 6 类卡顿 pattern（按出现顺序）

每一类都给出：

• task_id + instruction 关键句
• 触发模型行为的真实日志片段
• 持续时间 / 自愈方式
• 是否本 issue 之前观察过

2.1 task=786 — nmap 网络审计任务（今天惯犯，发作 2 次）

task.yaml 摘录（关键 instruction）：

instruction: |-
  You are a systems administrator performing a network audit of a simulated corporate LAN.
  ...
  1. Install `nmap` (it is not pre-installed) and use it to discover all active hosts on the 192.168.50.0/24 subnet.
  ...
  3. Produce a structured inventory report as a JSON file at `/home/user/network_audit_report.json`.
difficulty: medium
category: networking
max_agent_timeout_sec: 300.0

模型在该 task 触发 mass parallel pattern：单 turn 一次性发出 90+ 个几乎完全一样的 nmap -sV ... shell_exec。下面是 sample 30384（uid=e34e04e4）的 Turn 1 实际 ToolCallRequest 列表（94 个 tool_call，前 31 个原始日志摘录）：

Turn 1: executing 94 tool call(s).
[
  ToolCallRequest(tool_name='shell_exec', args={'id': '1',  'command': 'apt-get update && apt-get install -y nmap', 'block': True, 'timeout': 300}, ...),
  ToolCallRequest(tool_name='shell_exec', args={'id': '2',  'command': 'nmap -sn 192.168.50.0/24', 'block': True, 'timeout': 300}, ...),
  ToolCallRequest(tool_name='shell_exec', args={'id': '3',  'command': 'nmap -sV 192.168.50.0/24', 'block': True, 'timeout': 300}, ...),
  ToolCallRequest(tool_name='shell_exec', args={'id': '4',  'command': "nmap -sV 192.168.50.0/24 | grep 'open' | awk '{print $2}' | cut -d '/' -f1 | sort -n | uniq", ...}),
  ToolCallRequest(tool_name='shell_exec', args={'id': '5',  'command': "nmap -sV 192.168.50.0/24 | grep 'open' | awk '{print $2}' | cut -d '/' -f1 | sort -n | uniq | sort", ...}),
  ToolCallRequest(tool_name='shell_exec', args={'id': '6',  'command': "nmap -sV 192.168.50.0/24 | grep 'open' | awk '{print $2}' | cut -d '/' -f1 | sort -n | uniq | sort", ...}),
  ToolCallRequest(tool_name='shell_exec', args={'id': '7',  'command': "nmap -sV 192.168.50.0/24 | grep 'open' | awk '{print $2}' | cut -d '/' -f1 | sort -n | uniq | sort", ...}),
  # ... (id=5 之后的 90 个全部是同一句 `nmap -sV ... | sort` 复读，仅 tool_call_id 不同)
  ToolCallRequest(tool_name='shell_exec', args={'id': '94', 'command': "nmap -sV 192.168.50.0/24 | grep 'open' | awk '{print $2}' | cut -d '/' -f1 | sort -n | uniq | sort", ...})
]

每个 nmap -sV 192.168.50.0/24 在 docker 容器内要扫描整个 /24 子网（256 个 IP），单调用 ~3 min，串行处理 94 调用 ≈ 4h42min。agent_runner 不在 turn 内打日志，所以表面看起来"卡死了"，实际是在串行干活。

两次发作的实测时长：

• 第 1 次（issue env-pool 完整记录：架构 / 6 个踩坑 / 持久化配置 / 系统化验证脚本（issue #1/#2 末段退化的环境侧根因） #3 §7.4 已记，66 个 nmap 调用）: 自愈 ~3h45m
• 第 2 次（本 run，94 个 nmap 调用，更狠）: 自愈 6h09m（perf 276 train_wait_time = 4013s + 后续 1h+）

自愈机制：模型走完 94 个 tool_call → Turn 2 (1 call) → ... → Turn 10 max iterations → evaluation → close。全部靠 agent_runner.py:93 的 10-turn 上限兜底，pool 从未需要主动 kill。

2.2 task=96 — FHS Filesystem Hierarchy Standard 重组（24 MB 输出 spam）

task.yaml 摘录：

instruction: |-
  You are tasked with auditing and reorganizing a misconfigured Linux filesystem according
  to FHS (Filesystem Hierarchy Standard) standards.
  ...
  You must audit the current state of binaries and scripts scattered across `/bin`, `/sbin`,
  `/usr/bin`, `/usr/sbin`, `/usr/local/bin`, and `/usr/local/sbin`, identify which files are
  incorrectly placed, ...
difficulty: medium
max_agent_timeout_sec: 600.0

模型行为：单 turn 121 个并行 tool_call，全部是 find / 类全局扫描，每个返回 ~24 MB 输出。pool 端处理：

[2026-04-28 03:26:31] chat_agent.py:1270 - Tool 'shell_exec' result truncated: 23852518 -> ~8092 tokens
[2026-04-28 03:27:21] chat_agent.py:1270 - Tool 'shell_exec' result truncated: 23852518 -> ~8092 tokens
[2026-04-28 03:28:11] chat_agent.py:1270 - Tool 'shell_exec' result truncated: 23852518 -> ~8092 tokens
... (56 条同样的 truncate 日志，间隔 ~45-50s) ...

23,852,518 byte ≈ 22.7 MB 输出，每次截断到 8092 token。56 truncate × 45s ≈ 42 min，但整 sample 卡了 86 min 才走完所有 121 calls + Turn 2-10 + evaluation。

2.3 task=90 — Swap activity monitoring tool（5 分钟监控 = 强制等 5min）

task.yaml 摘录：

instruction: |-
  Create a swap activity monitoring tool that tracks memory and swap usage patterns over time
  and generates diagnostic reports.
  ...
  1. Monitor swap activity continuously over a configurable time period (with ability to
     run for at least 5 minutes with 1-second intervals)

任务自身要求"至少跑 5 分钟"，模型如果照做就一定要等 5min。当 group 内 8 个 sample 各 5min（部分还要重跑），整个 group 卡 60min+，两个慢 sample 各 ~60min。这不是 bug，是 task instruction 设定就慢。

2.4 task=456 — Python multi-process memory leak（Turn 9 静默 hang）

task.yaml 摘录：

instruction: |-
  You are given a Python multi-process data processing application in /app/data_processor.py
  that has a memory leak.
  ...
  - A coordinator process that distributes work to multiple worker processes
  - Worker processes that process data chunks
  - One worker (worker_id == 2) has a DataCache that accumulates data indefinitely

新失败模式：sample 30025 (uid 28cfb282) Turn 1-8 在 20s 内完成，Turn 9 之后彻底沉默 70min。最终自愈，可能是 SGLang generation timeout 或 router-side timeout。与前面"输出多" / "tool_call 多"不同，这次是单一 tool_call hang。

[2026-04-28 11:19:55] Turn 1: executing 1 tool call(s).
[2026-04-28 11:20:02] Turn 2: executing 1 tool call(s).
... (Turn 3-8 在 20 秒内全部完成)
[2026-04-28 11:20:15] Turn 8: executing 1 tool call(s).
... 70 min 完全沉默 ...
[2026-04-28 12:30 左右] 自愈

2.5 task=856 — Bash provisioning script (apt + tzdata + postfix)（慢 shell_exec）

task.yaml 摘录：

instruction: |-
  You are setting up an automated provisioning script for a Debian/Ubuntu server.
  ...
  1. Installs the following packages non-interactively using apt-get: `curl`, `wget`,
     `tzdata`, and `postfix`.

单 tool_call 慢但稳定推进：每个 Turn 之间间隔 5-10min（apt-get install 需要下载 + 配置 postfix），sample 35359 完成 10 个 turn ≈ 67min。

00:16:05  Turn 5: 1 tool_call
00:21:05  Turn 6 (+5min)
00:26:05  Turn 7 (+5min)
00:36:06  Turn 8 (+10min)
00:46:06  Turn 9 (+10min)
00:56:06  Turn 10 (+10min) → max iterations → eval → close

2.6（issue #3 §7.x 已记的同类，此次复发） task=210 secure_wipe.sh dead loop

issue #3 §7.6 已经记过类似 pattern，这次 run 同样有，所有 6 类全部自愈，0 次需要人工 docker rm。

---

3. 卡顿事件汇总表（实测 60h+）

#	task_id	触发模式	持续时长	自愈	类型
1	786 (1st)	nmap×66 复读	~3h45m	✅	mass parallel
2	96	FHS find / × 121 calls × 24MB output	~86min	✅	mass parallel + giant output
3	90 (×2 sample)	Swap monitoring 5 min/turn	~60min/sample	✅	task-required slow
4	456	Python memleak Turn 9 静默	~70min	✅	silent hang
5	786 (2nd)	nmap×94 复读	~6h09m	✅	mass parallel (复发)
6	856	apt + postfix 慢 shell	~67min	✅	shell_exec slow

累计训练空转损耗 ≈ 11h35m / 60h12m ≈ 19%。pool 自身没问题，问题在 dataset 这几个"慢任务"被频繁选中 + 模型上 mass parallel 复读。

---

4. 后续行动建议（dataset 侧治理）

4.1 短期：黑名单这 6 个 task

最简单的 patch：在 terminal-rl/dataset/seta_env_convert/train.jsonl 生成时跳过这几个 task_name：

BLACKLIST = {'786', '96', '90', '456', '856', '210'}  # 加 issue #3 §7.6 那几个

预期收益：消除 ~19% 训练空转。代价：1376 → 1370 task，影响微乎其微。

4.2 中期：在 agent_runner 加 wall-clock timeout

issue #3 主帖里讨论过。建议在 terminal-rl/agent_runner.py 加：

TOTAL_ROLLOUT_TIMEOUT = 30 * 60  # 30 min hard cap
async def run_episode(...):
    start_ts = time.time()
    while turn < max_iterations:
        if time.time() - start_ts > TOTAL_ROLLOUT_TIMEOUT:
            logger.error("Wall-clock timeout, aborting rollout")
            break
        ...

预期收益：把单 sample 卡顿上限从"取决于 task"压到固定 30min。

4.3 长期：奖励机制治理 mass parallel 复读

模型在 task=786/96 上发出 90+ 个完全一样的 shell_exec —— 这个行为是 GRPO 早期通过 reward shaping 学坏的（短期内多发命令 = 多次试错 = 偶尔 + reward）。可以在 rollout_log.py 或 reward 端加 parallel_dup_penalty（同一 turn 内重复 command 减分）。

---

5. 与 run-3 主帖的双向引用

• run-3 实验主帖（含 wandb 全程曲线 / accuracy 0.32→0.52 / mode-collapse 复盘 / 与 issue 实验记录：terminal-rl Qwen3-4B GRPO outcome-only 单节点 8×H200（10h，wandb lpurziy1） #1, Qwen3-8B terminal-rl run (45h, ~1100 steps): peak 0.45 acc → mode collapse #2 横向对比）→ HansBug/OpenClaw-RL#PLACEHOLDER
• 本 comment：env-pool 60h+ 实测层面（这页）

---

附录 A：本次 ckpt 列表（save_interval=8）

iter_0000007 ~ iter_0000279  (35 个 ckpt, 11h-60h 间隔覆盖完整训练)
latest_checkpointed_iteration.txt → 279
ckpt 目录: /nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/ckpt/qwen3-8b-terminal-rl/

附录 B：log 全文统计

log file size       : 457,176,650 byte (≈ 457 MB)
truncate-to-8092    : 5,415 events
Max iterations 10   : 32,129 events  (多数 sample 走完 10 turn)
Marking FAILED      :   711 events  (slime graceful 转 reward=0)
group_idx unique    : 4,560
rollout count       :   283
final train step    :   565