48 replies

Browser tool fails with timeout in Docker container (Hostinger VPS)

✅Solved

Environment:

• Image: ghcr.io/hostinger/hvps-openclaw:latest
• OS: Debian 13 (Trixie), Linux 6.8.0-100-generic
• Node: v22.22.0
• Chromium: 145.0.7632.75 (manually installed via apt)
• Driver: ChromeDriver 145.0.7632.109

Symptoms:

1. browser tool calls fail: Can't reach the OpenClaw browser control service (timed out after 15000ms).
2. openclaw browser status returns running: false, cdpReady: false.
3. ps aux shows no chromium or Xvfb processes running during/after the attempt.
4. Logs show initialization success but execution timeout:

info browser/service Browser control service ready (profiles=2)
...
error [tools] browser failed: Can't reach the OpenClaw browser control service (timed out after 15000ms)

Troubleshooting Attempted:

• Confirmed openclaw.json has browser.headless: true, noSandbox: true.
• Manually installed missing deps: apt-get install -y chromium-driver libnss3 libatk1.0-0 libatk-bridge2.0-0 libcups2 libdrm2 libxkbcommon0 libxcomposite1 libxdamage1 libxfixes3 libxrandr2 libgbm1 libasound2.
• Hard restarted gateway (pkill -f openclaw-gateway + start).
• chromium --version runs fine in terminal.
• Python requests script confirms connectivity to target site (ParentVue), but browser tool cannot launch.

Solution

3) Docker /dev/shm size (tiny

/dev/shm

/dev/shm

is a classic Chromium-crash trigger in containers)

df -h /dev/shm || true

df -h /dev/shm || true

Prevention ideas

- Stop things cleanly where possible (

openclaw browser stop

openclaw browser stop

/ graceful container stop instead of hard kill).
- If this becomes frequent, it’s worth filing a GitHub issue asking OpenClaw to auto-detect stale
SingletonLock
SingletonLock
(only when no Chromium PID is alive) and self-heal, because it’s a common papercut in container/VPS setups.

Net: your fix is fine, and the “locked file” points to an earlier crash/ungraceful stop more than anything spooky. If you paste