Docker-selenium: Cant set node max instance in version 3.5.2 but works in 3.4.0 just fine

[slugics]

Issue

Image(s): node-chrome
Docker-Selenium Image Version(s): 3.5.2-antimony
OS: Ubuntu 16

I am running following command so I can have 7 instances of chrome browser within a single container. It works just fine in 3.4.0-dysprosium but doesn't seem to work when updating to 3.5.2-antimony. Do I need to add more options to my command line ? Have the existing options change? Please advise! Thanks

docker run -d -e NODE_MAX_INSTANCES=7 -e NODE_MAX_SESSION=7 -v /dev/shm:/dev/shm --link selenium-hub:hub selenium/node-chrome:3.4.0-dysprosium

Expected Behavior -

Runs seven instances of chrome browser within a single container

Actual Behavior -

Runs single instance of chrome browser within a single container

[sramores]

Same here! I try 3.4.0-dysprosium version and goes ok. Thanks @slugics for this message. I've been trying for days and I thought my mistake.

[pschroeder89]

The standard 3.4.0 image doesn't work with these variables, either. Thanks for the tip about dysprosium.

[slugics]

Works just fine for me

On Sep 1, 2017 9:56 AM, "Paul Schroeder" [e-mail] wrote:

The standard 3.4.0 image doesn't work with these variables, either.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SeleniumHQ/docker-selenium/issues/547#issuecomment-326631724,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFJzJqFDHfrbTV9IqmOG2sLtpD2hBmxjks5seDctgaJpZM4PJUAG
.

[eyalzek]

Seeing the same behavior with 3.5.2, running 3.4.0-dysprosium works as expected

[niQo]

Latest working release is 3.4.0-ensteinium
this commit broke the all docker env vars https://github.com/SeleniumHQ/docker-selenium/commit/45304b7867098725c5e68b362ad126c21a89ef20

[niQo]

Seems that the fix is here #529

[slugics]

Nice. Is it in 3.5.3-astatine or should I wait?

[testphreak]

@niQo @ddavison Since the release of 3.4.0-francium only a single browser instance is being created per node/container. To confirm, I tried 3.4.0-einsteinium and I am able to setup multiple multiple browser instances per node/container. It appears to me that the environment variables aren't being applied correctly.

With any version greater than 3.4.0-francium -

With 3.4.0-einsteinium (I can see all browser instances) -

[niQo]

@testphreak the fix #529 have been merged, will be in next release.

[testphreak]

@niQo @Remi-p I believe #529 change has already been merged and released as 3.5.3-astatine on Docker Hub. Correct me if I am wrong @ddavison. I still see the same issue with not being able to set number of browser instances with this latest image.

[pschroeder89]

3.5.3 fixed this issue for me.
Unfortunately, I'm seeing other issues regarding Selenium not respecting BROWSER_TIMEOUT and TIMEOUT, so I'm sticking with 3.4.0.

[testphreak]

@scoderp what arguments are you passing when running the node containers? If you see my screenshot for 3.5.3 in my comment above I can only create one browser instance in each node container and I am passing in NODE_MAX_INSTANCES=5. The same command if you see my other screenshot in the same comment works with 3.4.0-einsteinium.

Also I'd love to know from @Remi-p what drove this change? Can someone point me to the issue that caused this change? This issue is prevents us from testing against the latest Chrome version/Firefox versions.

[Remi-p]

@testphreak Hi,
The first commit I made (0dd193a) was to move the config generation from the entry_point.sh (called at run) to the dockerfiles (used at build). I made that because some of us, using openshift, had files permissions problems.
When I realized generating the configuration at run time was used to pass environment variables, I restored the lines from all the entry_point.sh (7c31de1). If you do a git diff between my last commit, and a commit just before my first, the files entry_point.sh are not modified : git diff bf36a08 7c31de1

At the end of the day, what I made was adding a config generation inside the dockerfiles, so that a default configuration file is already inside the docker image.
One error I can think of is that the default configuration file cannot be modifyed by entry_point.sh. But I guess it should have raised an error during the tests, when the images were deployed...

And also I don't know if Docker Hub follows the tags in GitHub, but 7c31de1 doesn't seems to be in 3.5.3-astatine yet : https://github.com/SeleniumHQ/docker-selenium/commits/3.5.3-astatine

[pschroeder89]

@testphreak I'm using a docker-compose yaml file to set NODE_MAX_SESSION and NODE_MAX_INSTANCES under my node's "environment" section. My GRID_MAX_SESSION variable is set to 10 under my hub's environment section, for what that's worth. It began working again when I pulled selenium/node-chrome-debug:latest and selenium/hub:latest, which is 3.5.3.

I think you're better off staying on 3.4.0 einsteinium though, I see 40-50% failure rates on 3.5.3 due to sessions disappearing or intermittent "BROWSER_TIMEOUT" errors. I'll be writing a bug later today when I get more info on it.

[niQo]

@testphreak as I said, it's fixed in git but the release does not contain the fix. It will be in the next release.
I've build images from git and it works, you can build locally or wait for the next release.

[testphreak]

@niQo which branch are you referring to? If it's master, I build the images locally from master and it still doesn't set the number of instances correctly. I have a fix for the issue #563 pending review. Added you to it.

[niQo]

@testphreak I tried locally building latest code from master with env NODE_MAX_INSTANCES and NODE_MAX_INSTANCES set to 4 works fine. Have you tried with a fresh git clone ?

[testphreak]

@niQo thanks. I confirmed after doing a fetch/rebase that passing of environment variables to the node containers works when building locally. Looking forward to the next release with the fix.

[gtroshin]

Have the same problem with passing ENV vars with 3.5.3.
Only 3.4.0-einsteinium works correctly.
Some estimation about fix?

[niQo]

@gtroshinnc we're just waiting for the next release
@ddavison can you please publish a new release ?

[diemol]

I'll check that tomorrow morning, and if everything's ok, I'll build a new release.

[ddavison]

i pushed a release yesterday 3.5.3-boron. let me know if this can be closed, now?

[testphreak]

@ddavison noticed the new release last evening. Thanks for the release! Environment variables passed at runtime works for me now. Would be best for the OP to comment before closing the issue.

[eyalzek]

Works for me as well with 3.5.3-boron. @slugics care to comment?

[slugics]

Yep, it seems to work now in 3.5.3-boron. Thanks everyone for getting this
resolved quickly.

Slaven

On Thu, Sep 21, 2017 at 9:04 AM, Eyal Zekaria [e-mail]
wrote:

Works for me as well with 3.5.3-boron. @slugics
https://github.com/slugics care to comment?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SeleniumHQ/docker-selenium/issues/547#issuecomment-331203625,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFJzJsa7ABJOr1dNwOrl29GOgVy3uVlMks5skokegaJpZM4PJUAG
.

[testphreak]

@slugics please close the issue.

[slugics]

Issue is fixed

[gtroshin]

I confirm too, that new release 3.5.3-boron fixed this problem. Thank you!