- সারি
- ২৩ সেপ্টেম্বর, ২০২৬ এ ৭:০২ PM UTC
- লেখক
- Kamo
- মন্তব্য@ info: status
- 2266930
The first real Hosted Computer reached AWAKE and then stayed awake forever. Hibernation reported resumeConfigured: false, IdleWatcher only arms when readiness is true, so the machine held a node's memory with nothing to show for it but a lastError nobody reads. The wiring was all correct on disk — the grub.d fragment, the initramfs hook, the swapfile in fstab, and resume=UUID=... resume_offset=... in the generated grub.cfg. What never happened was the restart that puts any of it on /proc/cmdline, which is the only place the kernel reads it from. The restart was conditional on configure() reporting that it had just written the wiring. configure() is called from two places: the agent's boot thread, on every start, and /prepare-sleep, which computeservice POSTs at the end of provisioning. On this machine they overlapped — the boot thread finished update-grub 40 milliseconds AFTER the POST arrived, so the POST's configure() found both files already correct, reported no change, and skipped the restart. Correct code, both callers doing their job, permanent deadlock, and not one error anywhere. So the decision no longer asks who wrote a file. resume_restart_decision() asks the state: the running kernel has no resume=, a boot could fix that, and the wiring is already in grub.cfg. Both anti-loop guards are load-bearing, because the failure mode on the other side is rebooting somebody's computer in a cycle: - grub.cfg must already carry the exact string. update-grub runs with check=False, so it failing is real, and restarting without it reboots into the identical command line. - a stamp under /var/lib/kamo-hc records WHAT was restarted for, and outlives the reboot it guards. Same wiring twice means the kernel is dropping the command line and a second reboot would not help. A swapfile that MOVED is a different string, and earns a fresh attempt. Every path logs, refusals included. The bug was silent in both directions at once: nothing restarted and nothing said why not. configure() is also serialised now. Those two callers were running update-initramfs against the same initrd concurrently, which was luck rather than design. The boot thread gets the same self-heal, gated on config.json existing: on a first boot the provisioning push has not landed yet and restarting would pull the machine out from under it, but on every boot after that it is what recovers a computer whose resume offset a kernel upgrade invalidated, without waiting to be asked. Nine tests. The one that matters asserts that a caller seeing "no change" still gets the restart — the old suite tested the mechanism and passed while the system deadlocked.