Bug Report: Unreliable X11 Xvfb server in `browsers` images with new images

[mczub-om]

Describe the bug
This report is a continuation of #482, which was presumed fixed with the #501 image release. However, after upgrading to the cimg/node:20.20.0-browsers, we're continuing to see the error intermittently with similar frequency.

Original report:

Using a cimg/node:*-browsers Docker image when the CircleCI step "Spin up environment" is slow, a pipeline using the image receives the X11 environment variable DISPLAY, however the Xvfb server may not have completed its start, is unavailable and causes a pipeline failure.

If the Xvfb server is not running it causes a failure using the CircleCI Cypress Orb.

Cypress checks to see if the environment variable DISPLAY is defined and relies on there being an working X11 server available.

If DISPLAY is not defined, then Cypress will start its own Xvfb server.

The combination of DISPLAY defined and Xvfb not running, causes Cypress to fail and robs it of the chance to start its own server.

To Reproduce

This is a sporadic issue that occurs in approximately 5-10% of builds using the cimg/node:20.20.0-browsers image.

Expected behavior

When a Docker container is started using a Docker image cimg:node:*-browsers, it should reliably start an Xvfb server and ensure that it is ready before allowing further instructions to be executed.

It is not sufficient to just start the server in the background and hope for the best.

Workarounds

Use Automatic reruns with max_auto_reruns

Screenshots and Build Links
We are seeing similar build failures as previously shown in private org workflows using cimg/node:20.20.0-browsers.

Cypress failed to start.

This may be due to a missing library or dependency. https://on.cypress.io/required-dependencies

Please refer to the error below for more details.

----------

[1059:0115/194850.304947:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
[1059:0115/194850.501979:ERROR:node_bindings.cc(379)] Most NODE_OPTIONs are not supported in packaged apps. See documentation for more details.
[1059:0115/194850.906240:ERROR:ozone_platform_x11.cc(245)] Missing X server or $DISPLAY
[1059:0115/194850.906258:ERROR:env.cc(258)] The platform failed to initialize.  Exiting.

----------

Platform: linux-x64 (Ubuntu - 24.04)
Cypress Version: 14.3.2

Exited with code exit status 1

Additional context
Add any other context about the problem here.

[MikeMcC399]

@mczub-om

Thanks for opening a new issue for this ongoing problem.

The issue has been observed running https://github.com/cypress-io/circleci-orb/blob/master/.circleci/test-deploy.yml

We haven't seen this after updating to cimg/node:24.13.0-browsers.

Other possibilities for working around this issue that CircleCI may be able to implement:

• Increasing the Xvfb timeout
• Optionally disabling the complete /docker-entrypoint.sh of cimg/node:*-browsers images, if this is possible somehow
• Adding a parameter / environment variable to disable Xvfb startup optionally

As far as Cypress is concerned, it is not necessary for CircleCI to start an Xvfb server. So long the image includes the Linux xvfb, Cypress will start Xvfb of its own accord.

Also I wonder if there is a way to capture the logs from the Xvfb startup? The log section "Spin up environment" does not log this action.

[MikeMcC399]

@mczub-om

An example failed run is https://app.circleci.com/pipelines/github/cypress-io/circleci-orb/2151, which uses an older version of the orb.

Please remove this from your report. It is using cimg/node:22.17.0-browsers from before the fix. Your report should be about your environment, not the one I originally reported.

[MikeMcC399]

@david-montano-circleci

Perhaps you could advise @mczub-om if it's possible to gather any logs of Xvfb being started by the /docker-entrypoint.sh script when it is being used in a CircleCI pipeline?

If /docker-entrypoint.sh fails to start the Xvfb server within the timeout, should it stop the CircleCI pipeline from continuing and log an error?

As I mentioned in #482 (comment) Cypress' source code https://github.com/cypress-io/cypress/blob/develop/cli/lib/exec/xvfb.ts uses a 30 second timeout (30000 milliseconds) to start xvfb. I would guess that 30 seconds chosen by Cypress is an empirical value based on experience and it may be worth just updating the timeout in

cimg-node/variants/browsers.Dockerfile.template

Line 70 in 0d1d330

printf 'WAIT_TIMEOUT=10\n' | sudo tee -a /docker-entrypoint.sh; \

to a higher value correspondingly.

[david-montano-circleci]

Hello. I created a PR that allows to configure the behavior of the docker-entrypoint file: #503
If this is merged then a user can control both:

• the time out to wait for the xvfb server to start
• completely ignore or not waiting for the xvfb server to start
  This can be achieved during docker run by setting the following environment variables:
• INSTALL_XFVB: 1 for the default behavior or 0 to basically skip the docker-entrypoint
• WAIT_TIMEOUT: now 30 seconds by default but can be overwritten during container execution as well.

[MikeMcC399]

@david-montano-circleci

Thanks for attempting to improve the situation! I have tried this out and logged two new issues:

• Bug Report: Disable INSTALL_XFVB leaves DISPLAY set and Cypress fails #507
• Bug Report: Misspelled environment parameter INSTALL_XFVB #508

[MikeMcC399]

Updating to the cimg/node:24.13.1-browsers image (which has a default 30 second timeout), the Cypress CircleCI Orb has failed in the CircleCI pipeline 2168 in the Angular Application job only.

Spin up environment for this job shows 14.63s to start the container:

Using the v2 container runtime. For more details see: https://discuss.circleci.com/t/docker-executor-infrastructure-upgrade/52282
docker-agent version: 1.0.60818-995515e
task-agent version 1.0.311559-c75ab7fe
Downloading task-agent: success after 450.345221ms.
System information:
 Server Version: 5.5.2
 Storage Driver: overlay
  Backing Filesystem: xfs
 Cgroup Driver: systemd
 Cgroup Version: 2
 Kernel Version: 6.8.0-1040-aws
 Operating System: ubuntu
 OSType: linux
 Architecture: amd64

Starting container public.ecr.aws/eks-distro/kubernetes/pause:3.6
  image is cached as public.ecr.aws/eks-distro/kubernetes/pause:3.6, but refreshing...
8389103237f2: Already exists
23d07b917726: Already exists
3c69a9ca2c95: Download complete
Starting container cimg/node:24.13.1-browsers
Warning: No authentication provided, using CircleCI credentials for pulls from Docker Hub.
  image cache not found on this host, downloading docker.io/cimg/node:24.13.1-browsers
eeadc4d5b881: Already exists
8ee22aed3a96: Already exists
89fbcd2c1793: Already exists
e500fe2d72e8: Already exists
16669d79db54: Already exists
88a425b1d6ce: Already exists
4f4fb700ef54: Already exists
953cdd413371: Already exists
c3d696a0c1b8: Download complete
8aad60f822f7: Download complete
a8ea589d5600: Download complete
3551c54b817c: Download complete
b73d59040f27: Download complete
b0f53e908ead: Download complete
cee4cff2b972: Download complete

  Did not get image metadata for cimg/node:24.13.1-browsers: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.41/images/docker.io/cimg/node:24.13.1-browsers/json": context deadline exceeded
WARNING: docker image cimg/node:24.13.1-browsers does not specify an architecture
cimg/node:24.13.1-browsers:
  pull stats: download 165.9MiB in 21.077s (7.87MiB/s)
  time to create container: 14.63s
Time to upload agent: 1.835542533s
Time to start containers: 726.284442ms

When Cypress tries to run, it find no functioning Xvfb server and shows the error message

Missing X server or $DISPLAY

Container startup times

Job	Create container
Standard Npm Example	19ms
Custom Node Version Example	63ms
Yarn Example	48ms
Pnpm Example	55ms
Custom Install Example	26ms
Wait On Example	29ms
Angular Application	14.63s
Run CT in Parallel	36ms
Run CT Tests in Chrome	61ms
Run CT Tests in Chrome for Testing	255ms
Run CT Tests in Firefox	91ms
Run CT Tests in Edge	41ms

Jobs which succeeded had a container startup time <= 255ms. The failing Angular Application job showed a much longer container startup time of 14.63s, and as observed in the past, there appears to be a correlation between high container startup times and Xvfb failures.

Assessment

There are no logs available showing attempts of the Docker image to start Xvfb and so we don't know if increasing the XVFB_TIMEOUT would improve the success rate. It isn't clear whether the high container startup time could be the cause or the result of a problem to start the Xvfb server.

The lack of specific logs and sporadic nature of the failures makes it impossible to troubleshoot effectively.

Suggestion

Unless there is a possibility to better troubleshoot and fix the Xvfb failure, then the unreliable Xvfb startup script should be removed from future cimg/node:*-browsers images.