The rollback still had a path that ended with two intact swapfiles on disk and neither of
them running.
With the original already off and moved to .previous, a failed rename back returned
immediately - "the host may currently have no swap" - without trying to activate anything.
Both candidates were sitting right there: the old swapfile under its .previous name, and
the replacement that the earlier fix had preserved. That return threw away the whole point
of preserving them.
The rename back was never the requirement. The kernel activates a swap area by path and
does not care that the path ends in .previous, so the old swapfile is brought up where it
lies. The rollback now tracks both files by where they currently are rather than by a flag,
and works down the candidates: original at the managed path, original at .previous,
replacement wherever it ended up. Only when none of them activates does it report that the
host has no managed swap - and then that statement is true.
Two consequences fall out of tracking locations:
- A replacement that could not be moved aside is still on the managed path, so the restore
no longer renames the original over it. That rename would have unlinked one of the two
files this rollback exists to keep.
- When the original ends up serving from .previous the replacement is not released and
nothing is deleted. The host has swap, so nothing is urgent, but the managed path does not
hold what the ownership record describes - that is an operator's call, and the error names
the location of both files and the commands that finish it.
Three tests: the rename back fails and the previous swapfile is activated in place; it fails
and the previous swapfile will not activate either, so the replacement takes over; a live
replacement that cannot be released is left in place and nothing else is attempted. The
last one needed a swapoff failure, which the fake could not express before.
fix(daemon): let the docker events subsystem return to healthy [P1]
The outer loop recorded an error every time the events stream ended, and nothing ever
recorded a success for it. One Docker restart therefore pinned a failure in status
permanently while the replacement stream was running normally. The reconnect now clears it
and logs the recovery once.
The per-subsystem transition logic moved onto LastActionState as record_ok/record_err, so it
can be tested without the /run writes that set_ok/set_err perform. Clearing the last error
also clears its timestamp - otherwise status showed an empty error next to the time it
stopped being true.
fix(swap): drop transition leftovers once the managed swap is confirmed live [P1]
Leftovers were only cleared on the way *into* a resize. A process killed after the
replacement went live left .previous on disk indefinitely: the next run finds a valid,
active, correctly owned swapfile at the managed path, takes the fast path, and never looks.
A swapfile is commonly sized after RAM, so that is not a rounding error. They are now
dropped right after the managed swap is confirmed active, and only when inactive - an active
leftover means the kernel is still swapping to it, which is the interrupted-rollback case
that needs an operator.
This also replaces two tests that asserted nothing about production code: both rebuilt the
active-leftover check inline instead of calling it.
Docs: the resize transition and its three degraded outcomes are now written down in
IMPLEMENTATION_SPEC rather than living only in the code, the reconcile order gained the
cleanup step, per-subsystem error tracking is described, and the acceptance checklist gained
the fault cases to exercise on Debian - each one keyed to the exact wording the error must
carry.
cargo fmt --check, clippy -D warnings, cargo test --locked --workspace --release: 199 + 4
passed.
founder
383e67605a