Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RemoteWebdriver binds on a non ephemeral port #5211

Closed
phyllipecesar opened this issue Dec 12, 2017 · 2 comments
Closed

RemoteWebdriver binds on a non ephemeral port #5211

phyllipecesar opened this issue Dec 12, 2017 · 2 comments

Comments

@phyllipecesar
Copy link

Meta -

OS: Linux
Selenium Version: any
Browser: chrome, probably firefox as well
Browser Version: Any

How currently works

Once we create a webdriver.Remote selenium server tries to find an acceptable port to start the "new driver"(I'm not that familiar with the terms).

Digging into the code I noticed that we explicitly avoid ephemeral ports, probably to avoid race conditions with other systems binding on port 0.
This is the code path that does this:

private static int createAcceptablePort() {

Other systems that have full control of the host might have fixed ports for isolation, but selenium races with them.

The same thing happens with chromedriver, they have a similar approach but at least they have a fixed range that we can avoid:
https://cs.chromium.org/chromium/src/chrome/test/chromedriver/server/http_handler.cc?l=88

I think it is great the selenium actually finds a random non-ephemeral port, but this might have side effects on other distributed systems.

My proposal is to add a new capability to Remote:

It could be a port capability that would allow others to actually specify selenium which port it should run the new driver, another solution I'd like is to actually provide selenium server a range which we consider acceptable, the latter wouldn't require adding a new capability and we could control when starting the server.

@barancev
Copy link
Member

barancev commented May 7, 2018

Quite contrary, Selenium attempts to find a free ephemeral port, createAcceptablePort uses a system-dependent ephemeral port range detector.

Do you suggest to restrict port range from the standard ephemeral port range (for a given OS) to a narrower range? What motivates this decision?

@barancev
Copy link
Member

Closing the issue as the intention is not clear. We're ready to reopen it if you provide a better explanation.

@lock lock bot locked and limited conversation to collaborators Aug 15, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants