Watch Checks run into error Timeout "BrowserType.connect_over_cdp: Timeout 60000ms exceeded. Call log: <ws connecting> ws://playwright-chrome:3000/ "

[FurkanVG]

Describe the bug
When i reboot my host system, and then my docker compose for changedetection starts up, some checks are stuck in a specific error:

"Exception: BrowserType.connect_over_cdp: Timeout 60000ms exceeded. Call log: ws://playwright-chrome:3000/ "

If i have lets say 10 Checks, it is a random amount always after reboot. It can be 3, 5 or even 9 out of 10 being in the error above

Version
v0.47.06

How did you install?
docker compose:

version: '3.2'

services:
  changedetection:
    image: ghcr.io/dgtlmoon/changedetection.io:dev
    container_name: changedetection
    hostname: changedetection
    volumes:
      - ChangeDetection:/datastore
    ports:
      - "5000:5000"
    environment:
      - LOGGER_LEVEL=TRACE
      - PLAYWRIGHT_DRIVER_URL=ws://playwright-chrome:3000
      - BASE_URL=https://change.furrkan.de
    restart: unless-stopped
    depends_on:
      playwright-chrome:
        condition: service_started

  playwright-chrome:
    hostname: playwright-chrome
    image: dgtlmoon/sockpuppetbrowser:latest
    cap_add:
      - SYS_ADMIN
    restart: unless-stopped
    environment:
      - SCREEN_WIDTH=1920
      - SCREEN_HEIGHT=1024
      - SCREEN_DEPTH=16
      - MAX_CONCURRENT_CHROME_PROCESSES=10

volumes:
  ChangeDetection:
    external: true

To Reproduce

I dont think this is the case for everybody, it may be something with my host system. But like i said, if i reboot my host, and then the docker container start, it is in the error. If i manully restart the docker containers AFTER they were running already after reboot, then the error dont come back anymore.

Expected behavior
Checks should not run into error, even if i reboot my host. Im doing this same procedure for months where i reboot the host weekly and i had never the issue.

Desktop (please complete the following information):

• OS: Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-49-generic x86_64)
• Browser Playwright-Chrome (see Docker Compose)

Additional context
I can provide any logs if told wherre to get them.

Thanks!

[dgtlmoon]

Hmm the config looks OK, and if your 'recheck' them all, does it work again?

[FurkanVG]

Hi,
Rechecking all doesn't change anything, since it tries to check them anyway every 5mins.

Clearing the erroe and rechecking also doesnt help

[searchjaunt]

I'm facing the same behavior regularly lately. Each time it'll be a surprise how many of the watches will end up with this error.

[mvantschip]

I am also facing the same problem. Has anyone perhaps found a solution?

[Orcamm]

Also got the same issue on several of my tracking links. Any one know what's going on?

[searchjaunt]

With the latest update, it's happening a lot. Besides that error, I'm also getting Exception: Page.content: Target page, context or browser has been closed

[searchjaunt]

Not sure what the relation is, but the CPU demand is peaking when these errors happen

As you can see, when the CPU is otherwise not overloaded with other processes

[bryanwagg]

Just thought I would chime in herewith my experience of this issue as it turned out to be simple fix for myself when I was running into this same issue when using the new sockpuppet service. (previously was using selenium web driver, but proxy was not working anymore).

For Context I use docker compose on my Synology DS220+ Nas, and I think by default the synology firewall was blocking connectivity between containers by default (or possibly only the sockpuppet container reaching the internet?). I briefly remember having to set up a bridge (forgive me if details are lacking, it was over 2 years) and having to explicitly allow incoming and outgoing requests over a certain range (I use 172.17.0.0 - 172.17.0.10).

Having recently upgraded the changedetection.io version to a more recent one (again, cant give specifics as over 2 years old). My docker-compose.yaml was a little out of date, meaning the default hostnames were first of all incorrect compared to current version, networks misconfigured, and due to the mentioned firewall issue hostnames would not resolve resulting in me having to use container IP’s In the webdriver variables.

I could have dug a little deeper for the exact cause and also havent tested whether or not hostnames work now instead of specific container ips for PLAYWRIGHT_DRIVER_URL= but my set up is now working and would prefer not to mess around more.

TLDR:
Persistent Timeout issue mentioned by OP is more than likely down to inter - container connectivity (or possibly upstream from sockpuppet -> internet timeout). Would highly recommend debugging your containers by attaching a terminal session and trying to ping from one to the other and then to the outside world.

[erikdemarco]

I also got this recently for all my checks

[haenschen]

I also had this issue since a few versions. At the moment it seems to work again.

1. I explicitly set up a dedicated docker network, cdio-net
2. I reduced max concurrent chrome processes to 5

services:
  changedetection:
    image: ghcr.io/dgtlmoon/changedetection.io
    container_name: changedetection
    hostname: changedetection
    environment:
      - PLAYWRIGHT_DRIVER_URL=ws://playwright-chrome:3000
    volumes:
      - changedetection-data:/datastore
    ports:
      - 5000:5000
    restart: unless-stopped
    depends_on:
      playwright-chrome:
        condition: service_started
    networks:
      - cdio-net

  playwright-chrome:
    image: dgtlmoon/sockpuppetbrowser:latest
    container_name: playwright-chrome
    hostname: playwright-chrome
    cap_add:
      - SYS_ADMIN
    restart: unless-stopped
    environment:
      - SCREEN_WIDTH=1920
      - SCREEN_HEIGHT=1024
      - SCREEN_DEPTH=16
      - MAX_CONCURRENT_CHROME_PROCESSES=5
    networks:
      - cdio-net

volumes:
  changedetection-data:

networks:
  cdio-net: 

[DMW007]

For me it didn't help to reduce MAX_CONCURRENT_CHROME_PROCESSES in the chrome container. Instead, I had to reduce FETCH_WORKERS (env variable of changedetection.io itself) from 10 to 2. Now all checks seems to run successfully, without generating timeout errors.

I'm unsure why this is a problem now. It worked for over a year with the higher value and I didn't changed the hardware or increased the load on the server, which could explain this issue. So I guess this is related to an update of either changedetection.io or the chrome driver.

[huyz]

Thanks, FETCH_WORKERS=2 worked pretty well. FETCH_WORKERS=1 seems to work even better.

So I guess having too many workers slows down the processes enough that they all start hitting the timeout.

So strange that this wasn't a problem before…

[poornachandratejasvi]

this worked