[Bug] 1.3.179 集群节点上的 Claude 槽容器启动失败：内核 Cmd 路径回归（/usr/local/bin/kin-kernel 应为 /opt/kin/kin-kernel） #489

TL;DR：1.3.179 中，节点槽容器（Docker 形态）的 PID 1 命令从节点镜像内的实际路径 /opt/kin/kin-kernel 被改成了控制面本机槽专用的 /usr/local/bin/kin-kernel（该路径只在本机槽的 bind mount 下存在）。结果是 1.3.179 下在集群节点上新建的 Claude 槽全部启动失败（runc：stat ... no such file or directory）。

提交前自查

• 已搜索现有 Issues 与 CHANGELOG.md，没有找到本问题的重复报告。1.3.179 变更含 fix(cluster): allow GPT slots on cluster nodes #473（节点 GPT 槽）等。

环境

复现步骤

1. 接入一个集群节点（SSH / Docker / preflight 正常）。
2. 在节点构建槽镜像（也可省略，新建槽会自动触发）：

   POST /api/panel/cluster/nodes/<node>/slot-image
   { "kernel": "ubuntu-24.04", "runtime_type": "docker" }

3. 在该节点新建 Claude 槽（API 与面板「导入/新建」等价）：

   POST /api/panel/vms/create
   { "kernel": "ubuntu-24.04", "node_id": "<node>", "proxy_id": "px-local", "start": true }

4. 观察结果：接口返回 vm，但 status=error，schedule_disabled_reason 为：

   failed to create task for container: failed to create shim task: OCI runtime create failed:
   runc create failed: unable to start container process: error during container init:
   exec: "/usr/local/bin/kin-kernel": stat /usr/local/bin/kin-kernel: no such file or directory
   

5. 确认错误容器的 Cmd：

   $ docker inspect kin-04 --format '{{json .Config.Cmd}}'
   ["/usr/local/bin/kin-kernel","--gateway-worker","--config","/run/kin/kernel.json"]
   

6. 确认同一镜像内并不存在该文件：

   $ docker run --rm --entrypoint /bin/sh vm2api/kin-slot-ubuntu-24.04:8cab30022f5e \
       -c 'echo "[/usr/local/bin]"; ls /usr/local/bin/; echo; echo "[/opt/kin]"; ls /opt/kin/'
   [/usr/local/bin]
   kin-codex-kernel  kin-egress  kin-worker          # ← 没有 kin-kernel
   [/opt/kin]
   cc-node  cli-node  glibc239  kin-kernel  kin-kernel.bin
   

期望行为：容器 PID 1 使用节点镜像内的 /opt/kin/kin-kernel 启动，日志输出 {"message":"native host ready","slots":20,...}。

对照组（1.3.178 创建的节点槽，正常）：

Cmd=["/opt/kin/kin-kernel","--gateway-worker","--config","/run/kin/kernel.json"]

根因

src/lib/cluster/remote-slot.mjs → slotContainerBody() 在 1.3.179 被改成复用本机槽的命令构造函数：

// 1.3.178（正确；REMOTE_KERNEL_ENTRY = '/opt/kin/kin-kernel'）
-    Cmd: [REMOTE_KERNEL_ENTRY, '--gateway-worker', '--config', '/run/kin/kernel.json'],
// 1.3.179（回归）
+    Cmd: slotContainerCommand(vm),

• slotContainerCommand()（src/lib/vm/vm-runtime.mjs）是为控制面本机槽设计的：返回 '/usr/local/bin/kin-kernel'（wrap 模式为 /home/kincli/.kin/kin-kernel）；本机槽运行时会把内核 bind mount 到该路径，因此本机槽不受影响。
• 节点槽镜像是自包含的（src/lib/cluster/slot-image.mjs 的 payload）：内核烘焙在 /opt/kin/kin-kernel（660B wrapper 脚本，配合同目录 kin-kernel.bin + glibc239/）；/usr/local/bin 只有 kin-worker / kin-egress / kin-codex-kernel，从不包含 kin-kernel。
• 旁证：slot-engine.mjs 的 REMOTE_KERNEL_ENTRY 常量在 1.3.179 全库已无任何引用（死常量），改动痕迹明确。
• 疑似来源：fix(cluster): allow GPT slots on cluster nodes #473（节点 GPT 槽改动）复用 slotContainerCommand 时，未区分「本机 bind mount 路径」与「节点 baked 路径」。

影响范围

• 1.3.179 下，集群节点上所有新建 Claude（Docker）槽必然失败；已存在的容器不受影响（Cmd 已固化），但 reset / recreate / 迁移后同样会踩。
• 不受影响：控制面本机槽；KVM 形态（独立 kvmSlotContainerBody）；节点 GPT 槽（Cmd 为 sleep infinity，符合 fix(cluster): allow GPT slots on cluster nodes #473 设计）。

建议修复

方案 1（最小改动，恢复 1.3.178 行为，推荐）

--- a/src/lib/cluster/remote-slot.mjs
+++ b/src/lib/cluster/remote-slot.mjs
@@
+import { REMOTE_KERNEL_ENTRY } from '../vm/slot-engine.mjs'   // 或在现有 slot-engine import 中恢复该项
@@
-    Cmd: slotContainerCommand(vm),
+    Cmd: [REMOTE_KERNEL_ENTRY, '--gateway-worker', '--config', '/run/kin/kernel.json'],

方案 2（让共享函数感知放置形态）

export function slotContainerCommand(vm, { wrapKernel = false, baked = false } = {}) {
  if (isCodexVm(vm)) return ['sleep', 'infinity']
  const bin = baked ? REMOTE_KERNEL_ENTRY
            : wrapKernel ? '/home/kincli/.kin/kin-kernel'
            : '/usr/local/bin/kin-kernel'
  return [bin, '--gateway-worker', '--config', '/run/kin/kernel.json']
}
// remote-slot.mjs:  slotContainerCommand(vm, { baked: true })

回归测试建议：节点槽容器创建用例断言 Cmd[0] === REMOTE_KERNEL_ENTRY（本机槽仍断言 /usr/local/bin/kin-kernel），防止此类「两种形态复用漂移」再次出现。

临时规避（生产环境已验证）

在控制面容器内把 remote-slot.mjs 中该行改为字面量 /opt/kin/kin-kernel 版本，并 docker restart vm2api 后，同一节点上重建槽一次通过：

{"message":"native host ready","protocol_version":2,"slots":20,"timezone":"America/Los_Angeles",...}

容器 Up、面板「诊断」除未导入凭证（该槽的预期状态）外全绿。

附：vm-04 槽位记录（脱敏导出，供对照）

id=vm-04   kernel=ubuntu-24.04   runtime=docker (machine: 512m / 2 vcpu)   locale=en_US.UTF-8
timezone=America/Los_Angeles (proxy_geo)   node=<Ubuntu 22.04 x86_64 节点>   proxy=节点本地
修复前 Cmd: ["/usr/local/bin/kin-kernel", ...]   → 容器 start 失败（本 issue）
修复后 Cmd: ["/opt/kin/kin-kernel", ...]          → native host ready