selenium: Regression in all versions >= 3.8.1 Non-deterministic ConnectionResetError with chrome and chromedriver
Meta
OS: Ubuntu Trusty on travis ci Selenium Version: 3.8.1 Browser: Chromedriver 2.34.0 with Chrome
Expected Behavior
I can do the patch-level update from 3.8.0 to 3.8.1 without exeriencing any differences.
Actual Behavior
With 3.8.0 everything works fine, while 3.8.1 non-deterministically fails with ConnectionResetError: [Errno 104] Connection reset by peer
when trying to instantiate chrome.
Steps to reproduce
The problem occurs in my django tests, only on travis ci and even on travis ci not reliably, so I unfortunately I can’t provide a minimized example. The following is the reduced test boilerplate where the failure occurs.
from django.contrib.staticfiles.testing import StaticLiveServerTestCase
class ChromeDriverTestCase(StaticLiveServerTestCase):
browser = None
@classmethod
def setUpClass(cls):
cls.browser = Browser('chrome', headless=True,
executable_path="node_modules/.bin/chromedriver")
super(ChromeDriverTestCase, cls).setUpClass()
The chromedriver
npm package is locked to 2.34.0.
This yields the following traceback in case of an failure (full travis ci log for reference):
Traceback (most recent call last):
File "/home/travis/build/meine-stadt-transparent/meine-stadt-transparent/mainapp/tests/live/chromedriver_test_case.py", line 29, in setUpClass
options=options)
File "/home/travis/virtualenv/python3.6.3/lib/python3.6/site-packages/splinter/browser.py", line 63, in Browser
return driver(*args, **kwargs)
File "/home/travis/virtualenv/python3.6.3/lib/python3.6/site-packages/splinter/driver/webdriver/chrome.py", line 35, in __init__
self.driver = Chrome(chrome_options=options, **kwargs)
File "/home/travis/virtualenv/python3.6.3/lib/python3.6/site-packages/selenium/webdriver/chrome/webdriver.py", line 75, in __init__
desired_capabilities=desired_capabilities)
File "/home/travis/virtualenv/python3.6.3/lib/python3.6/site-packages/selenium/webdriver/remote/webdriver.py", line 154, in __init__
self.start_session(desired_capabilities, browser_profile)
File "/home/travis/virtualenv/python3.6.3/lib/python3.6/site-packages/selenium/webdriver/remote/webdriver.py", line 243, in start_session
response = self.execute(Command.NEW_SESSION, parameters)
File "/home/travis/virtualenv/python3.6.3/lib/python3.6/site-packages/selenium/webdriver/remote/webdriver.py", line 310, in execute
response = self.command_executor.execute(driver_command, params)
File "/home/travis/virtualenv/python3.6.3/lib/python3.6/site-packages/selenium/webdriver/remote/remote_connection.py", line 466, in execute
return self._request(command_info[0], url, body=data)
File "/home/travis/virtualenv/python3.6.3/lib/python3.6/site-packages/selenium/webdriver/remote/remote_connection.py", line 490, in _request
resp = self._conn.getresponse()
File "/opt/python/3.6.3/lib/python3.6/http/client.py", line 1331, in getresponse
response.begin()
File "/opt/python/3.6.3/lib/python3.6/http/client.py", line 297, in begin
version, status, reason = self._read_status()
File "/opt/python/3.6.3/lib/python3.6/http/client.py", line 258, in _read_status
line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
File "/opt/python/3.6.3/lib/python3.6/socket.py", line 586, in readinto
return self._sock.recv_into(b)
ConnectionResetError: [Errno 104] Connection reset by peer
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 21
- Comments: 33 (4 by maintainers)
Commits related to this issue
- Lock selenium version Maybe there was a breakage in 3.8.1 — committed to meine-stadt-transparent/meine-stadt-transparent by konstin 6 years ago
- Pin selenium version Getting Exception ConnectionResetError: [Errno 104] Connection reset by peer in travis. https://github.com/SeleniumHQ/selenium/issues/5296 suggests that version 3.8.1 up causes t... — committed to ONSdigital/rasrm-acceptance-tests by benjefferies 6 years ago
- Run all tests in travis (#46) * Run tests in travis * Add wait for services script * Use chrome headless for default mode * Dump html on failure to for debugging * Make certain tests retry if dat... — committed to ONSdigital/rasrm-acceptance-tests by benjefferies 6 years ago
- IGU-396 downgraded selenium again It still does fail on jenkins even though it works locally. s.a. https://github.com/SeleniumHQ/selenium/issues/5296 — committed to iguana-project/iguana by caucaMe 6 years ago
- Try Selenium version 3.8.0 The Github issue on Selenium here: https://github.com/SeleniumHQ/selenium/issues/5296 suggests that the problem began from version 3.8.1, so let's try out 3.8.0 and see if... — committed to ukgov-equality-hub/ethnicity-facts-and-figures by TheDoubleK 6 years ago
- Try Selenium version 3.8.1 The Github issue on Selenium here: https://github.com/SeleniumHQ/selenium/issues/5296 suggests that the problem began from version 3.8.1, so let's try it out and see if it... — committed to ukgov-equality-hub/ethnicity-facts-and-figures by TheDoubleK 6 years ago
- Bump Selenium to version 3.8.0 According to this issue: https://github.com/SeleniumHQ/selenium/issues/5296 - and confirmed by rigorous testing pushing up various branches with different Selenium ver... — committed to ukgov-equality-hub/ethnicity-facts-and-figures by TheDoubleK 6 years ago
- Attempt to fix error creating Chrome We occasionally see failures starting chrome with the error `Exception ConnectionResetError: [Errno 104] Connection reset by peer`. There seems to be an open bug ... — committed to ONSdigital/rasrm-acceptance-tests by benjefferies 6 years ago
- Attempt to fix error creating Chrome We occasionally see failures starting chrome with the error `Exception ConnectionResetError: [Errno 104] Connection reset by peer`. There seems to be an open bug ... — committed to ONSdigital/rasrm-acceptance-tests by benjefferies 6 years ago
- [toolchain] change selenium version, to fix failing travis builds https://github.com/SeleniumHQ/selenium/issues/5296 — committed to stefanhoelzl/vue.py by deleted user 6 years ago
- Bump Selenium to version 3.8.0 According to this issue: https://github.com/SeleniumHQ/selenium/issues/5296 - and confirmed by rigorous testing pushing up various branches with different Selenium ver... — committed to ukgov-equality-hub/ethnicity-facts-and-figures by TheDoubleK 6 years ago
- Pin selenium to 3.8.0 to fix known bug See https://github.com/SeleniumHQ/selenium/issues/5296 — committed to theatlantic/django-selenosis by fdintino 6 years ago
- Downgrade Selenium https://github.com/SeleniumHQ/selenium/issues/5296 — committed to open-contracting/extension-explorer by odscjames 6 years ago
- Downgrade Selenium to try and stop temperamental failures on Travis. https://github.com/SeleniumHQ/selenium/issues/5296 — committed to open-contracting/extension-explorer by odscjames 6 years ago
I’ve set up a repo to stress test the Python driver to reproduce it: https://github.com/kevlened/python-webdriver-stress-test
I used ChromeDriver 2.38.552518 and Chrome 66.0.3359.139, but I think the error is seen due to a change in the python client.
Between 3.8.0 and 3.8.1, this change went in. I haven’t dug into why this causes the issue (it should only open a socket briefly), but reverting it fixes the problem.
Reverting it also fixes these other errors I was seeing in chromedriver:
That makes me think that
common_utils.is_connectable()
isn’t properly closing sockets.I’ve got exactly same issue as @bySabi , using Selenium 3.13.0 with chromedriver seems to work fine on my windows machine, but when I use docker it has
[error 104]connection reset by peer
problem, and downgrading to 3.8.0 resolves this problem. Thanks to the solution, since I got stuck on this problem for hours.Here is my dockerfile of installing chromedriver
and complete error code
same problem for:
for a code:
here are the logs:
With Selenium
3.13.0
andchromedriver
its working fine on macos host but fail inside a docker container. Downgrading Selenium to3.8.0
in docker seems its workingTurns out that under this stress test, the errors are also raised with 3.8.0, so I think the errors I’m seeing may be a different issue.
The Node webdriver implementation retries requests 3 times on these types of connection errors. I can open a PR to handle the errors in a similar way, but it would simply mask the error.
@chadawagner I’m curious what happens if instead of a delay, you add
socket_.shutdown(socket.SHUT_RDWR)
before it. The docs here say: