Playwright mot en innlogget Chrome via CDP på Wayland

Playwright kan styre en kjørende, innlogget Chrome via CDP (remote debugging). På en Wayland/GNOME-maskin feiler dette stille på fire punkter: profilen, miljøvariablene, prosessdrap og prosessens levetid. Feilmeldingene sier lite om årsaken. Under står hvert punkt og oppsettet som virker.

Chrome nekter debug-port på standardprofilen

Nyere Chrome-versjoner åpner ikke debug-porten mot den vanlige brukerprofilen. Pek Chrome mot en egen profilmappe, og slå av den avanserte nøkkellagringen.

google-chrome \
--remote-debugging-port=9222 \
--user-data-dir=/tmp/chrome-debug \
--password-store=basic
Egen --user-data-dir gir en ren profil som porten får binde seg til. --password-store=basic hindrer at Chrome henger på et keyring-oppslag og venter på en dialog som aldri vises.

Prosessen når ikke skjermen uten riktig miljø

Skjematisk diagram over miljøvariablene DISPLAY, XAUTHORITY, XDG_RUNTIME_DIR og DBUS som kobler Chrome-prosessen til Xwayland-skjermserveren på Wayland

Startes Chrome fra et skall uten grafisk kontekst, finner den verken skjerm eller sesjonsbuss og avslutter. Under Xwayland må fire miljøvariabler være satt: skjerm, X-autentisering, runtime-katalog og DBUS-adresse.

export DISPLAY=:0
export XDG_RUNTIME_DIR=/run/user/1000
export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
export XAUTHORITY=/run/user/1000/.mutter-Xwaylandauth.XXXXXXXAUTHORITY
er den som skaper problemer. Xwayland lager et nytt filnavn for autentiseringsfila ved hver innlogging, så en hardkodet sti virker i dag og feiler etter neste innlogging. Hent verdien fra miljøet til en GUI-prosess som allerede kjører.

PID=$(pgrep -u "$USER" -f gnome-shell | head -n1)
XAUTHORITY=$(tr '\0' '\n' < /proc/$PID/environ | grep '^XAUTHORITY=' | cut -d= -f2)
export XAUTHORITY
Ikke drep din egen prosessNår noe henger, er det nærliggende å drepe alt som matcher portargumentet. Det mønsteret matcher som regel også startskriptet ditt, så skriptet dør og nettleseren lever videre.

# Farlig: matcher lett ditt eget skript
pkill -f "remote-debugging-port=9222"

# Tryggere: match bare Chrome-binæren
pkill -x chrome
Start Chrome løsrevet fra skalletStartes Chrome som barn av skallet, dør den når skallet lukkes eller SSH-sesjonen faller. setsid løsriver prosessen fra skallet.

Topologidiagram som viser hvordan et Python-Playwright-skript kobler seg til en kjørende Chrome-nettleser over CDP på port 9222 og overtar den innloggede sesjonen

setsid google-chrome \
--remote-debugging-port=9222 \
--user-data-dir=/tmp/chrome-debug \
--password-store=basic \
>/tmp/chrome.log 2>&1 < /dev/null &
Koble Playwright på den kjørende sesjonenNår porten er oppe, kobler Playwright seg til over CDP og bruker den innloggede sesjonen direkte. Det startes ingen ny nettleser, og du trenger ikke logge inn på nytt.

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
browser = p.chromium.connect_over_cdp("http://localhost:9222")
context = browser.contexts[0]
page = context.pages[0]
print(page.title())
SjekklisteEgen --user-data-dir og --password-store=basicDISPLAY, XDG_RUNTIME_DIR og DBUS_SESSION_BUS_ADDRESS sattXAUTHORITY hentet fra en kjørende GUI-prosess, ikke hardkodetStart med setsid, og drep aldri på portmønsteretMed dette oppsettet kan nettleserautomatiseringen kjøres fra cron eller en agent uten tilsyn.