Bug 验证报告：PR686 发现 1（stop_vllm_process.sh 自匹配自杀）

• run-id: bugverify-pr686-f1-20260903-01
• 验证日期: 2026-09-03
• 结论: ✅ 确认是 bug，必现（deterministic）。实测证据与代码推断一致，且机制比原记录更强：自匹配不依赖 $1 参数——部署路径 /tmp/vllm/ 本身即含 "vllm"。
• 建议 Issue 标题: [Medium][optix/multihost_infer] stop_vllm_process.sh 按命令行模式自匹配，清理调用链自杀、重试保障失效并误杀无关进程

Problem

vllm_worker_manager.py 的 cleanup_all_workers() 以 bash /tmp/vllm/stop_vllm_process.sh vllm 在各 worker 上清理残留 vllm 进程。脚本用 pgrep/pkill -i -f "${name}" 按完整命令行匹配，而调用链自身命令行必然包含该模式（$1 实参 + 部署路径 /tmp/vllm/）。首次 pkill -9 即命中脚本自身进程/会话 shell，脚本在 attempt 1 中途被 SIGKILL：5 次重试与 WARNING 兜底成为死代码；真正的 vllm 进程只是"恰好"在同一轮 pkill 中被顺带杀掉，从而掩盖了自毁。-f 模式过宽还会误杀命令行中偶然含 "vllm" 的无关进程。

Reproduction（命令 + 配置，等价于生产调用）

生产调用即 fabric conn.run("bash /tmp/vllm/stop_vllm_process.sh vllm")（sshd 侧等价于 bash -c 'bash /tmp/vllm/stop_vllm_process.sh vllm'，命令行含模式）。复现在任意 Linux 上执行：

# Step 0: 部署脚本（与生产同路径 /tmp/vllm/）
mkdir -p /tmp/vllm && cp <repo>/contrib/optix/multihost_infer/multihost_inference_optimization/script_template/stop_vllm_process.sh /tmp/vllm/

# Step 1 (T2 触发组, 无受害者): 生产同形调用
bash -c 'bash /tmp/vllm/stop_vllm_process.sh vllm; echo INNER_SURVIVED=$?'
# 预期(脚本设计): 最多 5 轮 kill 尝试后输出 WARNING，INNER_SURVIVED=0
# 实际: 仅输出 "killing residual process matching: vllm (attempt 1/5)" 后整个调用链被 SIGKILL，
#       INNER_SURVIVED 永不打印，子进程退出码 137

# Step 2 (T1 完整矩阵): 假 vllm 受害者 + 偶然含 vllm 的无辜进程 + 干净对照
setsid bash /tmp/vllm/fake_vllm_worker.sh &      # cmdline 含 /tmp/vllm/... → 模拟真实 vllm
setsid tail -F /tmp/vllm/decoy.log &             # cmdline 偶然含 vllm → 误杀面
setsid sleep 3000 &                              # 干净对照
bash -c 'bash /tmp/vllm/stop_vllm_process.sh vllm; echo INNER_SURVIVED=$?'

# Step 3 (T3b2 真对照组): pattern 仅经环境变量通道、任何 cmdline 均不含它
MODEL_EVAL_STATE_KILL_PROCESS_NAME=zzznomatchzzz bash /tmp/vllm/stop_vllm_process.sh
# 实际: "no residual process matching: zzznomatchzzz"，退出 0 —— 脚本设计行为正常，
#        证明触发条件就是「pattern 出现在某进程（含自身）命令行中」

# Step 4 (T5): 环境变量通道 + pattern=vllm（wrapper cmdline 干净）
MODEL_EVAL_STATE_KILL_PROCESS_NAME=vllm bash /tmp/vllm/stop_vllm_process.sh
# 实际: 脚本进程自身被 SIGKILL（"Killed bash /tmp/vllm/stop_vllm_process.sh"），退出 137
#        —— 部署路径 /tmp/vllm/ 单独足以自匹配

Test Results（WSL2 Ubuntu-24.04 实测）

Expected

清理脚本完成至多 5 轮 kill-验证循环，仍存活时输出 WARNING；仅杀死目标 vllm 服务进程；调用方拿到可判读的退出码。

Actual

任何 pattern 为 "vllm" 的现实调用（$1 通道或环境变量通道皆然）中，脚本在 attempt 1 的 pkill -9 -i -f vllm 处杀死自身调用链（脚本进程、会话 shell；docker 模式下宿主机侧 docker exec 链同样命中），重试循环与 WARNING 成为死代码。真实 vllm 进程仅因同一轮 pkill 被顺带击中才"看起来能用"；命令行偶然含 "vllm" 的无关进程被误杀。

Root Cause

pgrep/pkill -i -f 对完整命令行做子串/正则匹配，且只排除进程自身 PID、不排除祖先；而模式串必然出现在调用链自身的命令行中（$1 实参与部署路径 /tmp/vllm/ 两处）。procps-ng 4.0.4 实测确认该语义。

Environment

• 主机: Windows 10.0.26200 x64；复现环境: WSL2 Ubuntu-24.04（kernel 6.6.114.1-microsoft-standard-WSL2），bash + procps-ng 4.0.4
• 被测代码: contrib/optix/multihost_infer/.../script_template/stop_vllm_process.sh 与 vllm_worker_manager.py，经 git diff e8fd687..HEAD 验证自 PR686 合入（2026-08-25）后字节级未变
• 调用方上下文: cleanup_all_workers() 经 fabric（direct SSH 或 docker exec）远端执行；本机 WSL 复现与 sshd 派生 shell 的命令行形状一致（bash -c 'bash <script> <pattern>'）

Impact

• 多机寻优每轮 run 前后的残留清理：重试保障失效，清理失败仅表现为日志中莫名的 cleanup 非零退出/断连（warn=True 只记日志不中断主流程）
• 误杀面：目标节点上任何命令行含 "vllm" 的无关进程（如 tail -f /tmp/vllm/*.log、编辑相关文件产生的进程）被 SIGKILL
• 不影响数据持久性；主流程有 warn=True 兜底，故定级 Medium（次要功能可靠性 + 误杀风险），与原记录一致

事实 / 推断 / 待确认

• 事实：上表 4 组实测结果；脚本与调用方代码自合并未变；pkill 进程仅排除自身不排除祖先（procps-ng 行为，实测 T5 脚本进程被杀）。
• 推断：fabric 直连/docker exec 两种生产模式下的 sshd shell / docker exec 链同样命中（命令行形状相同，本机无 NPU 多机环境无法端到端实测，标注为推断）。
• 待确认：无（核心机制已实测闭环）。

修复方向（供 Issue 讨论）

1. 杀进程名单排除自身与全部祖先（沿 /proc/self/status 的 PPid 链收集后 -v 过滤），最小改动；
2. 收紧模式：按进程名精确匹配（pgrep -x）或锚定服务进程特征（如 vllm serve|VLLM::EngineCore）；
3. 更彻底：改用 start_workers 时记录的 _remote_pids 定点 kill；
4. 部署目录改不含 "vllm"（如 /tmp/ms_worker_scripts），消除路径自匹配（与 1/2 配合）。