fix: don't start Xvfb in start.sh — sitespeed.io manages its own

Our start.sh was starting Xvfb on :99, then sitespeed.io tried to start
its own on :99, failed with exit code 1, and Chrome couldn't get a
working display. sitespeed.io is designed to manage Xvfb per test run.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
2026-04-07 10:13:08 +02:00
parent ad5881302e
commit ea70d34d7f
2 changed files with 4 additions and 6 deletions

View File

@@ -31,7 +31,8 @@ export function runTest(job, onLine) {
sitespeedArgs.push('--browsertime.chrome.args', 'disable-gpu'); sitespeedArgs.push('--browsertime.chrome.args', 'disable-gpu');
} }
const env = { ...process.env, DISPLAY: process.env.DISPLAY || ':99' }; // Do not force DISPLAY — sitespeed.io starts and manages its own Xvfb
const env = { ...process.env };
let child; let child;

View File

@@ -8,10 +8,7 @@ fi
echo "[start.sh] SITESPEED_BIN=${SITESPEED_BIN:-NOT FOUND}" echo "[start.sh] SITESPEED_BIN=${SITESPEED_BIN:-NOT FOUND}"
# Start virtual framebuffer so Chrome/Firefox have a display to render into # Do NOT start Xvfb here — sitespeed.io starts its own Xvfb instance
Xvfb :99 -ac -screen 0 1920x1080x24 +extension RANDR & # per test run. Starting one here causes a conflict on :99 and breaks Chrome.
export DISPLAY=:99
sleep 1
exec node /app/app.js exec node /app/app.js