node-firefox often fails with "Error: cannot open display: :99"

[anto-ac]

Meta -

Image(s):
node-firefox

Docker-Selenium Image Version(s):
3.14.0-arsenic and previous versions

Docker Version:
17.06.2-ce

OS:
Debian 3.16.43-2 (2017-04-30)

Setup:
wdio + grid with a hub, 8 chrome nodes and 8 firefox nodes.
Tests run on a Jenkins slave

Expected Behavior -

All nodes work as expected throughout the duration of the test run.

Actual Behavior -

Sporadically, one (sometimes more) firefox nodes fail to have a session initiated, leading to the spec assigned to that session not being executed and the whole . The error is:

[33mselenium-firefox-1_1  |[0m Failed to connect to Mir: Failed to connect to server socket: No such file or directory
[33mselenium-firefox-1_1  |[0m Unable to init server: Could not connect: Connection refused
[33mselenium-firefox-1_1  |[0m Error: cannot open display: :99
[32;1mui-test_1             |[0m ERROR: Process unexpectedly closed with status 1
[32;1mui-test_1             |[0m Build info: version: '3.13.0', revision: '2f0d292', time: '2018-06-25T15:32:19.891Z'
[32;1mui-test_1             |[0m System info: host: '2eb130e13a7b', ip: '172.19.0.4', os.name: 'Linux', os.arch: 'amd64', os.version: '3.16.0-4-amd64', java.version: '1.8.0_171'
[32;1mui-test_1             |[0m Driver info: driver.version: unknown
[32;1mui-test_1             |[0m remote stacktrace: 
[32;1mui-test_1             |[0m firefox
[32;1mui-test_1             |[0m     at new RuntimeError (/home/xxx/node_modules/webdriverio/build/lib/utils/ErrorHandler.js:143:12)
[32;1mui-test_1             |[0m     at Request._callback (/home/xxx/node_modules/webdriverio/build/lib/utils/RequestHandler.js:316:39)
[32;1mui-test_1             |[0m     at Request.self.callback (/home/xxx/node_modules/webdriverio/node_modules/request/request.js:186:22)
[32;1mui-test_1             |[0m     at emitTwo (events.js:126:13)
[32;1mui-test_1             |[0m     at Request.emit (events.js:214:7)
[32;1mui-test_1             |[0m     at Request.<anonymous> (/home/xxx/node_modules/webdriverio/node_modules/request/request.js:1163:10)
[32;1mui-test_1             |[0m     at emitOne (events.js:116:13)
[32;1mui-test_1             |[0m     at Request.emit (events.js:211:7)
[32;1mui-test_1             |[0m     at IncomingMessage.<anonymous> (/home/xxx/node_modules/webdriverio/node_modules/request/request.js:1085:12)
[32;1mui-test_1             |[0m     at Object.onceWrapper (events.js:313:30)

[diemol]

Hi @anto-ac,

Is it possible for you to provide have a test that can help us to replicate the issue? Even if it only happens every now and then, we can just run it several times and wait until it happens.

[anto-ac]

Hi @diemol,

I guess I could put something together. Something like

• a few specs
• a wdio config
• a docker compose file

Or did you have something else in mind?

[anto-ac]

I was wondering, though, if you had any ideas already. There were some issues with this reported in the past, some of which where addressed. For example: #184

[diemol]

Yeah, but in theory that was resolved.

So, yes, a project that help us replicate it would be really helpful, thanks.

[anto-ac]

Also, just to clarify, I have never seen it when running the tests on a local machine (admittedly different version of docker, different host os), but only when the tests run in Jenkins.

[anto-ac]

@diemol I have created a repo here: https://github.com/anto-ac/node-firefox-cannot-open-display

[anto-ac]

Issue is not “awaiting answer” anymore I don’t think.

[diemol]

No, it is not...

I tried to reproduce the issue within a new VM with Jenkins and using the repo you provided (by the way, thanks for that, I wish all issues provided something like that)... But I could not, I ran the Jenkins job over 50 times and I could not see the error.

Nevertheless, maybe there is some context missing? Are there more jobs running at the same time with the same images?

I did some googling and I saw reports of the same issue for Firefox even without docker, always with display :99. So maybe we need to research more in that direction.

[anto-ac]

Unfortunately it happens very sporadically. We’ve tried to reproduce it consistently, but failed to do so. I thought that perhaps it would happen more often if more than one job was running on the same Jenkins slave at the same time, but failed to find any correlation.

Our original code adds a unique prefix to all containers when created (in order to avoid different jobs using the same containers). I’ve removed that bit from the example for convenience.