`list_procs` matched on `readlink -f /proc/PID/exe`. Once the binary is
rebuilt -- which happens constantly here, `cargo test` alone is enough -- the
link reads "<path> (deleted)" and -f resolves it to something that matches
nothing. The scan then finds zero processes, so `start`'s orphan check passes
and a second instance can be launched alongside a stray.
Not theoretical. Two orphans were running undetected tonight:
pid 592731 :42327 a stale-cert redirector left from testing check-tls-parity,
still serving F9:16:1A -- the exact certificate whose
mismatch cost three live gates
pid 542693 :42230 a Blaze sidecar debug build from 03:12
Neither was in a client path, so neither was doing harm, but a stray listener
serving the known-bad certificate is precisely what should never sit around
unnoticed.
Fixed by using plain readlink and stripping the " (deleted)" suffix. Shown both
ways: with the bug `status` reports no processes at all for a live pid; with the
fix it reports 604454. The pidfile path was unaffected, which is why `stop` kept
working and hid this.
Committing updates refs/heads/<branch>, not the HEAD file, so watching HEAD
alone left the stamp one commit behind -- observed live, the banner read
a84a72e immediately after 2337431 was committed. build.rs now also watches the
resolved branch ref.
Belt and braces, since cargo still cannot see every source change: sidecar.sh
compares the binary's stamped commit against the tree's real HEAD at launch and
says so loudly on a mismatch. An evidence artefact that names the WRONG commit
is worse than one that names none.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The compiled-in dirty flag cannot be trusted for this job. Cargo does not
re-run a build script when another crate's source changes, so editing the
adapter and rebuilding the host leaves it reading 'clean' -- verified by
appending a line to the adapter and watching the flag not move.
So the stamp now only names the commit, and the real safeguards run at the
moment they matter and cannot go stale:
* sidecar.sh checks the working tree at LAUNCH and warns.
* check-live-parity.sh REFUSES on a dirty tree, since it produces the
artefact a migration decision is made from. ALLOW_DIRTY=1 overrides for a
throwaway check.
Both scope to the three migration crates, so unrelated submodule dirt does not
trigger them -- a warning that is always on is a warning nobody reads.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Prerequisites for the live FIFA A/B. Two safeguards here exist because the
corresponding failure actually happened, not because it was imagined.
BUILD IDENTITY. build.rs stamps commit + working-tree cleanliness; the host
prints commit, tree state, profile and a fingerprint of the bundled config
table at startup, into both the log and the trace. A dirty tree prints an
explicit "do NOT treat results from this binary as parity evidence" warning.
The previous step left four sidecars running, two serving mutated builds, and
nothing in their output said so.
SIDECAR LIFECYCLE (sidecar.sh). start/stop/status/check-orphans/with. Start
refuses when any sidecar is already running or the port is busy. Stop kills,
waits, then PROVES it: PID gone AND port free AND no stray processes, failing
if any check does not hold. `with -- CMD` traps EXIT/INT/TERM so cleanup runs
however the command exits.
Bug found and fixed while testing it: orphan detection used `pgrep -f`,
which matched any process whose command line merely mentioned the name --
including the shell running the test script. It now matches the resolved
executable via /proc/PID/exe. `pgrep -x` is unusable because Linux truncates
the process name to "openfut-blaze-h".
BLAZE SWITCH (blaze-switch.sh). Redirects Blaze to the sidecar with a scoped
NAT rule instead of editing the frozen Python oracle, whose redirector
advertises a hardcoded BLAZE_PORT = 42130. Rules match only <LAN_IP>:42130;
127.0.0.1:42130 is deliberately left alone so Python stays reachable on
loopback and the A/B compares real Python against real Rust. Verified both
directions live: LAN->Rust with the switch on, LAN->Python with it off.
Bug found and fixed: `off` reported success while two rules remained active
and rollback had NOT happened. It matched `--comment "tag"` with quotes this
iptables does not emit -- and the verification used the SAME broken matcher,
so it confirmed its own failure. A rollback that lies is worse than one that
fails. Now matched on the bare tag, verified with iptables-save plus a
tag-independent check that nothing still redirects the port.
Second flaw fixed: `sidecar.sh stop` originally warned about a live switch
and then stopped anyway, creating the exact broken state it warned about. It
now REFUSES, with --force as the deliberate override.
The general rule this all converges on, now stated in the README: a
verification must not share the failure mode of the thing it verifies.
116 tests still passing; clippy clean; Python backend untouched and contract
suite 446/446. NAT table left clean, no orphan processes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
funman300