Container self-exits with "socat ... bind :9222: Address already in use" after 1-2 requests

[andremmfaria]

Summary

When running the Docker image, the entrypoint socat proxy and Chromium's own DevTools listener appear to race for port 9222. Intermittently socat loses the bind, logs Address already in use, and the container exits (code 1), tearing down the browser session mid-use. This makes any multi-request workflow unreliable without an external restart loop.

Environment

• Image: tilion/fortress:latest, pulled 2026-09-17, digest sha256:b4f331693d3db25d70d814a99ed0da6be433d884e18d5af1cf3e6f3a2969569b (image created 2026-07-15, 611MB compressed / 2.48GB on disk)
• Docker: 29.7.2, Linux host
• Run command: docker run -d --network host tilion/fortress:latest --remote-debugging-port=9222
• Client: Python Playwright via connect_over_cdp("http://localhost:9222")

Steps to reproduce

1. Start the container as above.
2. Wait ~5-8s for /json/version to answer on 9222.
3. Drive it over CDP: open a page, navigate, read content.
4. Issue a second/third navigation.

Actual

After roughly 1-2 requests / 20-40s uptime, stderr shows:

socat[7] E bind(5, {AF=2 0.0.0.0:9222}, 16): Address already in use

The container then exits with code 1 and the browser session dies. Observed 3 times in one session; a full container restart (~5-8s) recovers it until the next occurrence. The same run command succeeded, then failed, then succeeded again, which points to a startup race rather than a misconfiguration.

Expected

Chromium's DevTools endpoint and the socat proxy should not contend for the same port; the CDP endpoint on 9222 should stay up across many requests.

Notes

• Also seen (harmless, but noisy): missing dbus / XDG_RUNTIME_DIR warnings on stderr.
• Happy to capture full container logs or test a proposed entrypoint fix.