已开启
msdev exec 对 docker-container env 调用 SSH RPC 失败且错误消息为空 #1
rookie_hongchuan创建于  16 天前
rookie_hongchuan成员
16 天前 创建

环境信息

  • 节点:dev-123
  • 环境:vllm-dspark-train(docker-container runtime,基于容器 vllm-dspark-train
  • 镜像:quay.io/ascend/vllm-ascend:v0.22.1rc1
  • 容器类型:privileged 容器
  • msdev 版本:0.10.0

复现命令

msdev exec --env vllm-dspark-train --cwd /home/hongchuan/msModelSpec-Dev -- bash -c '<长命令 / 交互命令,如 torchrun ...>'

报错输出

error: SSH RPC to environment 'vllm-dspark-train' failed: 
[exited with code 2]

关键点:failed: 之后错误消息为(没有任何内容),本地进程退出码为 2,难以定位根因。

三组诊断对照

通道 命令 结果
msdev host env(同一节点) msdev exec --env dev-123 --cwd / -- bash -c '...' 正常执行任意命令
容器本体(docker 直连) docker exec vllm-dspark-train bash -c 'echo ok' 正常(docker ps 显示该容器 Up)
msdev docker-container env msdev exec --env vllm-dspark-train ... 失败:failed: 后错误消息为空,退出码 2
  • 只有 msdev exec --env vllm-dspark-train ...(docker-container runtime 的 env)在投入交互/长命令(例如包含 torchrun)时失败。
  • 复现时序:失败发生在通过该 env 执行带 torchrun / 长命令时;偶发之后重试仍失败;切换到 host env + docker exec 兜底后工作正常。
  • 结论:问题出在 msdev 的容器 env 通道层,不是目标容器或业务命令本身。

期望行为

  • 通过该 env 正常执行进程;或
  • 失败时给出有意义的错误消息(而不是 failed: 后为空),以便区分是容器 exec 失败、命令超时、远端退出码透传问题,还是 RPC / stream 传输层(stream 关闭、退出码解析)错误。
likedislike
rookie_hongchuan成员
16 天前 评论:

已修复:错误消息不再为空(commit f12e4f9,已推 main,340 用例通过)

空消息根因

msdev exec 走流式 RPC(exec.stream),出错分支此前把「远端 msdevd rpc 进程的非零退出 + 其 stderr 原文」直接拼进 failed: {detail}。当远端进程以非零退出但 stderr 为空(例如 proxy 侧早期退出、OCI/SSH 层失败——proxy_rpc 的 empty-request 分支就是「错误打 stdout、返回码 2、无 stderr」)时,detail 为空串,于是打印出 failed: 后什么都没有、本地退出码 2,完全无法定位。对比之下,非流式路径对空 stderr 本来就有兜底,唯独流式路径漏了。

修复内容(commit f12e4f9

  1. 流式 RPC 失败消息必定包含退出码;stderr 为空时兜底为 no error output from remote msdevd
  2. 远端进程 rc=127 时给出可操作提示(run msdev node bootstrap <node>),与 _call_once 路径对齐
  3. 新增 2 个回归测试:空 stderr 场景 + rc=127 场景

请复验

再跑之前的命令,现在会看到类似:

error: SSH RPC to environment 'vllm-dspark-train' failed (exit code 2): no error output from remote msdevd

若消息仍无实质内容,说明根因在更深的容器侧。请把下面两条的输出一起发来,可顺藤摸瓜:

  • msdev exec --env vllm-dspark-train --cwd <dir> --result-json -- bash -c 'echo probe'
  • docker exec vllm-dspark-train bash -c 'echo probe; exit 2'

说明:我这边没有 dev-123 环境,无法直接复现 torchrun 场景;本次已把「无法诊断」的传输层问题关掉,容器侧根因需要上面的可读输出来继续追。

likedislike
rookie_hongchuan成员
16 天前 评论:

复现探针结果(已在 dev-123 / vllm-dspark-train 上实测)

用这台机器注册的 dev-123 节点 + vllm-dspark-train env 跑了 10 组探针,docker-container 通道各路径均正常

探针 结果
简单命令(whoami/pwd) ok, exit 0
命令自身 exit 2 正确透传退出码 2(这是正常路径,非 RPC 失败)
长时流式输出(8s×8 行) ok, exit 0
多进程(Popen×3) ok, exit 0
stderr 洪泛 1000 行 ok, exit 0
--result-json 捕获 + exit 2 JSON 结果正确、退出码 2
stdin 转发 不转发:容器内 read 立即 EOF(rc=1) —— 若命令依赖 stdin 会读到关闭的流
torch 可用性 torch 2.10.0+cpu、torchrun 存在
最小 torchrun(standalone/1 proc/CPU) ok, exit 0

两点结论:

  1. 你那份「SSH RPC failed:(空)」已被修复(commit f12e4f9),任何此类失败现在都会带退出码和可读原因。
  2. 通道本身没有系统性故障;悬而未决的容器侧偶发根因需要你那条真实命令——issue 里复现命令是占位符(<长命令 / 交互命令,如 torchrun ...>)。请把实际命令贴出来(不想公开可脱敏),我用已修复的 CLI 原样重放,直接定位是 docker exec 报错、进程组被杀、还是资源问题。

附带发现:msdev exec 不把本地 stdin 转发给远端命令(设计如此,RPC 请求占用 stdin)。如果那条真实命令会读 stdin(交互式),这就是确定失败点,值得一并确认。

likedislike