sparanoidandGitHub 864cae2493 fix(docker): clean up stale Xvfb lock so container survives restarts (#284) ...

On `docker restart`, `/tmp` is preserved across container instances, so the
previous Xvfb's `/tmp/.X99-lock` survives into the new container. The new
Xvfb sees the existing lock and refuses to start, leaving the container
with no X server. Every Chrome launch then dies with "Missing X server or
$DISPLAY", and `cloakserve` returns 502 from `/json/version` forever.

Any orchestrator that restarts on unhealthy (the README-recommended
healthcheck + `restart: always`, autoheal sidecars, etc.) then enters a
permanent restart loop because every restart hits the same broken state.

This is silent for first-time users: the container appears to start
successfully (Xvfb did launch *once*), then degrades only after the first
restart. The fix is one line in the entrypoint: remove the stale lock
before starting Xvfb.

Fixes #283

2026-05-21 05:27:49 +02:00

..

cloakserve

fix: guard cloakserve websocket origins (#240)

2026-05-17 19:40:44 +02:00

cloaktest

feat: Docker Hub image, cloaktest CLI, and example UX improvements

2026-03-05 05:09:29 +01:00

docker-entrypoint.sh

fix(docker): clean up stale Xvfb lock so container survives restarts (#284)

2026-05-21 05:27:49 +02:00