Okay, after a bit of fun trying to reproduce and bisect, I've discovered why it's happening. It's actually my docker-compose upgrade that did it, not docker's upgrade. I have the same issue with selenium/standalone-firefox, I've tried with different tags and it can be reproduced in all of them. Here are the results of a docker diff on the container, I hope it helps. C /homeC /home/seluserA /home/seluser/.cacheA /home/seluser/.cache/mozillaA /home/seluser/.cache/mozilla/firefoxA /home/seluser/.mozillaA /home/seluser/.mozilla/extensionsA /home/seluser/.mozilla/firefoxA /home/seluser/.mozilla/firefox/Crash ReportsA /home/seluser/.mozilla/firefox/Crash Reports/InstallTime3932A /home/seluser/.mozilla/firefox/Crash Reports/eventsA /home/seluser/DesktopC /tmpA /tmp/.X11-unixA /tmp/.X11-unix/X99A /tmp/.X99-lockA /tmp/hsperfdataseluserC /varC /var/tmp.
We had the same problem with the standalone-chrome-debug image. The image executes the following file /opt/bin/entry-point.sh. It tries to start an xDisplay on port 99.0. After we restarted the image the following lock file was present /tmp/.X99-lock. Because of this file xvfb could not be started.We wrapped the selenium image in our own docker image and added a script to remove this lock file on startup of the container.Removing the file /tmp/.X99-lock on startup of the container fixed our problem. I can reproduce the error event on selenium/standalone-chrome-debug:2.53.0. Here's the output of./opt/bin/entrypoint.sh call: root@1adb1d203eb4:/#./opt/bin/entrypoint.shLooking for lock file: /tmp/.X??-lockWaiting xvfb.-bash: 169.254/16: No such file or directoryWaiting xvfb.Waiting xvfb.Waiting xvfb.Waiting xvfb.Waiting xvfb.Waiting xvfb.Waiting xvfb.Waiting xvfb.Waiting xvfb.root@1adb1d203eb4:/# Error: Couldn't connect to XServer:99.0 03:04:47 passing arg to libvncserver: -rfbport 03:04:47 passing arg to libvncserver: 5900 03:04:47 -usepw: found /root/.vnc/passwd 03:04:47 x11vnc version: 0.9.13 lastmod: 2011-08-10 pid: 169 03:04:47 XOpenDisplay(':99.0') failed.
03:04:47 Trying again with XAUTHLOCALHOSTNAME=localhost. 03:04:47. 03:04:47. XOpenDisplay failed (:99.0).
![Xvfb-run: Error: Xvfb Failed To Start Xvfb-run: Error: Xvfb Failed To Start](/uploads/1/2/4/2/124296144/864626012.png)
x11vnc was unable to open the X DISPLAY: ':99.0', it cannot continue. There may be 'Xlib:' error messages above with details about the failure.Some tips and guidelines:.
An X server (the one you wish to view) must be running before x11vnc isstarted: x11vnc does not start the X server. (however, see the -createoption if that is what you really want). You must use -display, -OR- set and export your $DISPLAYenvironment variable to refer to the display of the desired X server.- Usually the display is simply ':0' (in fact x11vnc uses this if you forgetto specify it), but in some multi-user situations it could be ':1', ':2',or even ':137'. Ask your administrator or a guru if you are havingdifficulty determining what your X DISPLAY is. Next, you need to have sufficient permissions (Xauthority)to connect to the X DISPLAY.
![Xvfb-run: Xvfb-run:](/uploads/1/2/4/2/124296144/217634416.png)
ERROR: Xvfb failed to start, consult the lines above for errors. Now a new process is started for each build and left running (and. Travis CI fails randomly with 'xvfb-run: error: Xvfb failed to start'. Example: whereas the full.
Here are some Tips:- Often, you just need to run x11vnc as the user logged into the X session.So make sure to be that user when you type x11vnc.- Being root is usually not enough because the incorrect MIT-MAGIC-COOKIEfile may be accessed. Nice observation. To the developers: what is that code trying to do?
I interpret that it's passing the root environment through, but just for variables which are set in the seluser environment. And why given that -E is being passed? The intent there is lost and the code makes it very hard to read and determine what will happen. Presumably it's possible to achieve the intended effect with less code and in a less error-prone way.
I would have sent a patch if I could determine what the purpose is. So I deleted the container and image for selenium/standalone-chrome-debug.Re-ran docker run -d -P selenium/standalone-chrome-debug.Container still has exited with 127. See docker ps -a results below. Thought this was fixed in latestselenium/standalone-chrome-debug?CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES5af24880c451 selenium/standalone-chrome-debug '/opt/bin/entrypoint' 2 minutes ago Exited (127) 2 minutes ago cockywrightdocker logs -f 5af24880c451Looking for lock file: /tmp/.X??-lockWaiting xvfb.-bash: 169.254/16: No such file or directoryWaiting xvfb.Waiting xvfb.Waiting xvfb.Waiting xvfb.Waiting xvfb.Waiting xvfb.Waiting xvfb.Waiting xvfb.Waiting xvfb. The following bug, signaled above, occurs only on Docker4Mac (and not on Docker4Windows) even when a proxy is not specified at the Docker Engine level: Waiting xvfb.-bash: 169.254/16: No such file or directoryThis is due to the default value of the Exclude textfield of the Advanced pane of Docker4Mac settings which is greyed out initially but nevertheless taken into account by the Docker Engine. One can see it using this simple command: $ docker run -it -rm alpine envPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binHOSTNAME=68427e1a6e8cTERM=xtermnoproxy=.local, 169.254/16HOME=/rootIf this value is changed to a single space character, the noproxy variable disappears: $ docker run -it -rm alpine envPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binHOSTNAME=99a77bf3380eTERM=xtermHOME=/root= it is a docker4mac bug.