[vpetersson-bot]

Fixes the upgrade failure reported in #3437.

The problem

An upgrade can abort with port is already allocated while nothing is listening on that port:

Error response from daemon: failed to set up container networking: driver
failed programming external connectivity on endpoint anthias-redis-1 (...):
Bind for 127.0.0.1:6379 failed: port is already allocated

Docker keeps host-port reservations in libnetwork's store. An endpoint that is never torn down cleanly leaves its reservation behind (daemon killed mid-upgrade, or a board that browns out while the stack is running), so the container collides with its own ghost on the next bring-up. The symptom always lands on a service that publishes a host port.

This is not the srly-ose-redis case already handled above in the same script, where a real pre-rebrand container still holds 6379. Here no container holds the port at all, so removing containers by name does not help.

Reported on the forum across three Pi 4B devices, then independently by a second user: https://forums.screenly.io/t/6688

The fix

Capture the up -d output through tee so progress still streams to the operator, and on failure check it for that specific error. If it matches, take this compose project down, which releases every endpoint it owns and removes its network, then retry the bring-up once. Any other failure aborts with its original exit code, unchanged.

The recovery is deliberately scoped to this project's own network. The workaround circulating in the forum thread is rm /var/lib/docker/network/files/local-kv.db, which drops every user-defined network on the host and takes the web UI down with it. The second reporter hit exactly that and had to repair it by re-running the script. A test now guards against anyone reintroducing it.

Testing

Three paths exercised against a stubbed docker:

Path	Result
up fails with the stale reservation	recovery down runs, retry succeeds, exit 0
up succeeds first time	no down, exit 0
up fails for any other reason	aborts with the original exit code, no down

The temp log is cleaned up on all three.

Then a real end-to-end upgrade on the Pi 4B rig with the patched script: pull, signature verification, full stack recreated, redis healthy, web UI answering 200, stale images purged, exit 0.

Four tests in tests/test_upgrade_containers_script.py (two existing, two new); the existing ordering guard was widened to assert the reboot gate sits below every bring-up rather than the only one. Full non-integration suite passes (2591 tests); ruff check, ruff format --check and mypy clean on the touched files.

Note: the original libnetwork state does not reproduce on Docker 29.6.1 (SIGKILLing dockerd with the stack up reconciles cleanly on restart), so this is written against the reported symptom rather than a live repro.

🤖 Generated with Claude Code

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud