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

TCP socket remains after chrome is quitted #1025

Open
ManiMozaffar opened this issue Feb 3, 2023 · 4 comments · May be fixed by #1575
Open

TCP socket remains after chrome is quitted #1025

ManiMozaffar opened this issue Feb 3, 2023 · 4 comments · May be fixed by #1575

Comments

@ManiMozaffar
Copy link

Hello, ever since using python 3.11 with UC v3.2.1, I have an issue where socket doesn't close after chrome is quitted. so I created a test enviroment
Running with proxy --> 185.151.247.141

while True:
      options = uc.ChromeOptions()
      options.add_argument('--no-first-run  --password-store=basic')
      options.add_experimental_option("debuggerAddress", "127.0.0.1:2222")
      options.add_argument(f"--user-data-dir={self.data['profile_path']}")
      executable_path = f'C:\\Users\\Administrator\\Desktop\\Project\\drivers\\chromedriver (2)'
      options.add_argument('--disable-backgrounding-occluded-windows')
      self.driver = uc.Chrome (options=options, driver_executable_path=executable_path, enable_cdp_events=True)
      self.driver.get("google.com")
      self.driver.quit()
      time.sleep(30)

after .quit is called, during sleeping time there should be no TCP connection alive

netstat -ano | find "185.151.247.141"
  TCP    192.168.1.31:50385     185.151.247.141:14432  ESTABLISHED     19652
  TCP    192.168.1.31:50386     185.151.247.141:14432  ESTABLISHED     19652

and sometimes it'd be CLOSE_WAIT.
Any reason why?
I think a socket is made in cdp method that has not closed, which caused this, but I couldn't find it.

After few hours of running, all ports get occupied by program, and then it allows no TCP connection which will break everything.

@ManiMozaffar
Copy link
Author

Setting keep_alive to False, would fix the problem

self.driver = uc.Chrome (options=options, driver_executable_path=executable_path, enable_cdp_events=True, keep_alive=False)

Well not because it closes connection but because connection goes to TIME_WAIT, which then will timeout after few seconds according to your windows TCP configuration.
But this problem did not happen with undetected 3.0.3 and py3.8.9, any reason why this error was produced at the first place?

@ultrafunkamsterdam
Copy link
Owner

ultrafunkamsterdam commented Feb 3, 2023

Why not try:..

while True:
    driver = uc.Chrome()
    driver.get("google.com")
    time.sleep(10)
    driver.quit()

No options required as its all included
Edit: forgot to read. While sleeping. There is still a reference so it's not gc'd

@ManiMozaffar
Copy link
Author

ManiMozaffar commented Feb 3, 2023

Why not try:..

while True:
    driver = uc.Chrome()
    driver.get("google.com")
    time.sleep(10)
    driver.quit()

No options required as its all included Edit: forgot to read. While sleeping. There is still a reference so it's not gc'd

Well I tried to call gc collector, and it doesn't still help.
Deleting driver did not fix the issue as well. (del self.driver)

The initial connections running is much more than 2, so I don't think gc has to do anything with this case, because otherwise it'd have not closed the rest as well

DURING Runtime:

netstat -ano | find "185.151.247.141"
  TCP    192.168.1.31:10350     185.151.247.141:14432  ESTABLISHED     21648
  TCP    192.168.1.31:10351     185.151.247.141:14432  ESTABLISHED     21648
  TCP    192.168.1.31:10366     185.151.247.141:14432  TIME_WAIT       0
  TCP    192.168.1.31:10368     185.151.247.141:14432  ESTABLISHED     16012
  TCP    192.168.1.31:10369     185.151.247.141:14432  ESTABLISHED     16012
  TCP    192.168.1.31:10372     185.151.247.141:14432  ESTABLISHED     16012
  TCP    192.168.1.31:10373     185.151.247.141:14432  ESTABLISHED     16012
  TCP    192.168.1.31:10374     185.151.247.141:14432  ESTABLISHED     16012
  TCP    192.168.1.31:10375     185.151.247.141:14432  CLOSE_WAIT      16012
  TCP    192.168.1.31:10376     185.151.247.141:14432  CLOSE_WAIT      16012
  TCP    192.168.1.31:10379     185.151.247.141:14432  CLOSE_WAIT      16012
  TCP    192.168.1.31:10380     185.151.247.141:14432  CLOSE_WAIT      16012
  TCP    192.168.1.31:10382     185.151.247.141:14432  CLOSE_WAIT      16012
  TCP    192.168.1.31:10383     185.151.247.141:14432  ESTABLISHED     16012
  TCP    192.168.1.31:10384     185.151.247.141:14432  ESTABLISHED     16012
  TCP    192.168.1.31:10385     185.151.247.141:14432  ESTABLISHED     16012
  TCP    192.168.1.31:10386     185.151.247.141:14432  ESTABLISHED     16012
  TCP    192.168.1.31:10392     185.151.247.141:14432  ESTABLISHED     16012
  TCP    192.168.1.31:10393     185.151.247.141:14432  ESTABLISHED     16012
  TCP    192.168.1.31:10394     185.151.247.141:14432  ESTABLISHED     16012
  TCP    192.168.1.31:10395     185.151.247.141:14432  ESTABLISHED     16012
  TCP    192.168.1.31:10396     185.151.247.141:14432  ESTABLISHED     16012
  TCP    192.168.1.31:10399     185.151.247.141:14432  ESTABLISHED     16012
  TCP    192.168.1.31:10400     185.151.247.141:14432  ESTABLISHED     16012
  TCP    192.168.1.31:10401     185.151.247.141:14432  ESTABLISHED     16012

The result would have been same without those options.
disable-backgrounding-occluded-windows is kinda necessary since because it focus the window on chrome, which many website tries to check if your chrome is focused or not when you interact (click) on the website. With the window's gui ,it's impossible to perform a click command without chrome being focused on the windows, so as a suggestion I recommend putting this as default option when starting undetected driver.

EDIT: you put sleep before quitting, the case here is that connections are supposed to be closed with the driver. so it makes sense if you put sleep after quit.

@ManiMozaffar
Copy link
Author

I have fixed this issue in my own PR #1031

@ManiMozaffar ManiMozaffar reopened this Sep 21, 2023
@ManiMozaffar ManiMozaffar linked a pull request Sep 21, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants