The Gitea site test has been red since 03b0e13, and the cause was not the disk:
Error response from daemon: network with name wpci-147-net already exists
id was "wpci-$$". A Gitea job runs in a fresh container where the shell gets a
low PID, and those REPEAT across runs — so the name collides with the leftovers
of any earlier run that did not clean up, and every subsequent run landing on
the same PID is wedged permanently. The same script never collides on a laptop,
where PIDs are large and varied, which is why this was invisible outside the
runner.
That also corrects something this repo believed: "the containers are already
safe (wpci-<pid>)" was written about concurrent sessions on one machine, where
it is true. It does not hold across container boundaries, where the PID space
restarts.
Two changes. The name now carries the epoch and $RANDOM, so it is unique per
run even in a container that always starts at the same PID. And because the
name is now unique to this run, anything already using it is debris from a
crashed run and is ours to clear, so the containers and network are removed
before they are created — without that, one wedged name stays wedged forever,
which is what happened here.
Proven both ways: staging a stale wpci-147-net reproduces the exact daemon
error under the old scheme, and the new pre-remove creates cleanly over it.
Two consecutive real site tests then ran green, leaving zero wpci-* networks
and zero wpci-* containers, with no leak warning from the check added in the
previous commit.
Worth recording how that was measured. A global `docker volume ls | wc -l`
around one of those runs showed a delta of 2 — none of it this run's. Several
sessions share this box and run these container pairs concurrently, so a
neighbour's volumes read as your leak. The attributed check inside cleanup(),
which asks the containers what they own, reported nothing and was right.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
