A Chrome killed uncleanly leaves SingletonLock in the chrome-profile
volume, naming the hostname and pid that took it. Both change when the
container is rebuilt, so the next Chrome reads it as "another computer
holds this profile" and exits at startup — permanently, since the volume
outlives every recreate.
The only symptom was a bare connection reset at 9222: socat accepts,
start_browser fires, Chrome dies, wait_for_browser bails on browser_alive
and the helper closes the socket. Chrome's stderr went to /dev/null and
the give-up path logged nothing, so neither docker logs nor the client
could tell a dead browser from a dead network — which is most of why this
cost an afternoon. Both are now on the container's stderr.
Clearing the lock at boot is safe because container_name pins the volume
to one container: nothing can hold the profile when that line runs. A
lock left mid-lifetime is self-healing (same hostname, dead pid), so boot
is the whole exposure.
sulthan
6489f97686