Session is not cleaning up all chromedriver processes

[Gary-Osteen-Q2]

For versions 0.0.8 and 0.0.9, the test run does not shut down all 2.31-x64-chromedriver processes when finished. This does not happen when using firefox/geckodriver. When running more than one spec, multiple 2.31-x64-chromedriver processes get started but one will always remain per test run. I have tested this with 1 and 2 specs in the wdio conf.

Current workaround that works for me:

Add this to your wdio.config.js file.

afterSession: async function(){
    // workaround to make sure the chromedriver shuts down
    await browser.end().pause(1000);
},
after: async function(){
    // workaround to make sure the chromedriver shuts down
    await browser.pause(1000);
}

[Gary-Osteen-Q2]

Further testing shows this does not happen when you manually start the standalone jar before running the tests.

[joshden]

I am seeing the same issue with multiple specs. As a workaround, I set the Chrome capability maxInstances to 1 to run the specs serially.

// wdio.conf.js
capabilities: [{
    // maxInstances can get overwritten per capability. So if you have an in-house Selenium
    // grid with only 5 firefox instances available you can make sure that not more than
    // 5 instances get started at a time.
    maxInstances: 1,
    browserName: 'chrome'
}],

[Gary-Osteen-Q2]

Interesting if that works. This might be acceptable for smaller projects, but when you have a large collection, this would slow things down a lot if you are use to running 3 or more parallel instances.. That said, it might work for me for now, but won't be a sustainable workaround for long.

[dangmai]

Yup I'm running into this same issue as well, and setting maxInstances to 1 is at best a temporary work around.

[FlippieCoetser]

The workaround does not work for me. With each manual run of a set of tests, a new 2.31-x64-chromedriver process is created, even if I have the maxInstances set to 1.

[FlippieCoetser]

A workaround, which is not ideal but works for me, is to use shelljs to run a kill command, in the afterSession hook:

shell.exec('taskkill /FI "IMAGENAME eq 2.33-x64-chromedriver" /F')

[rgustavsson]

I'm using chromedriver 2.33-x64 through the `services: [ 'selenium-standalone' ] and the chromedriver instances do not stop themselves even if I set maxInstances to 1.

    maxInstances: 1,
    capabilities: [
      {
        maxInstances: 1,
        browserName: 'chrome'
      }

in my package.json:

    "webdriverio": "4.9.9",
    "wdio-selenium-standalone-service": "0.0.9",

[christian-bromann]

@rgustavsson so it's more an issue of the selenium-standalone service?

[rgustavsson]

@christian-bromann not sure.

@Gary-Osteen-Q2 mentioned:

Further testing shows this does not happen when you manually start the standalone jar before running the tests.

So I was assuming that it works when running the selenium-standalone service manually.

[mike-suggitt]

Bumping this. Any thoughts on what might be causing this yet? It's causing issues on our build servers as we get up to 100+ running instances of chromedriver! Plus it means we can't clean down the workspace between builds because of the same said running process.

[Miladinho]

I have experienced this on both Chrome and Firefox with its geckodriver

[goatsy]

Me too. On Windows and Mac. Really problematic.

[ashmind]

Tried to do some research on this (on Windows).

It seems that selenium-standalone starts java.exe and then something (Java?) starts 2.33-x64-chromedriver. When kill is called (see below), it kills java.exe but not 2.33-x64-chromedriver: https://github.com/webdriverio/wdio-selenium-standalone-service/blob/ccb38ec3edd1b2bf80d3592ba3412e6bf0075179/lib/launcher.js#L36-L38

Seems like an issue in selenium-standalone, however I can't find anyone reporting it there, so maybe something specific in how it is invoked?

[phil-lgr]

Experiencing as well on windows 10:

 "wdio": "1.0.3",
    "wdio-browserstack-service": "0.1.14",
    "wdio-jasmine-framework": "0.3.2",
    "wdio-junit-reporter": "0.3.1",
    "wdio-selenium-standalone-service": "0.0.9",

[phil-lgr]

@ashmind did you find anything new? Debugging this morning to see what's up.

[phil-lgr]

I just tried putting a:

 after: async () => {
        await browser.pause(2000);
    },

and it seems to fix it, no more chromedriver left behind.

[christian-bromann]

mhm .. but why did it fix it when we wait in the afterHook?

[phil-lgr]

False alert 😅 I still get the idle at the end..

@christian-bromann any workaround you could think of or info I could gather?

[christian-bromann]

no idea, something must be up when trying to kill these processes

[phil-lgr]

@FlippieCoetser's solution seems to be the thing to do for now 🙏

[janardanb]

Hi , I am also facing the same issue.. @christian-bromann @phil-lgr is there any solution for it?

[christian-bromann]

@amolebhojane sorry but I can't look into this atm, any PRs or suggestion for fixes are highly appreciated

[prantlf]

I reproduced the problem using just selenium-standalone and webdriverio modules. I logged the issue for selenium-standalone.

I use a short delay after uninitializing the WebdriverIO client as a workaround to get the chromedriver process stopped:

const webdriverio = require('webdriverio')
const client = webdriverio.remote({...})
client.init()
  ...
  .end()
  // the following line helps stopping the chromedriver process after
  // killing the selenium process returned by the start method
  .pause(100)

[ghost]

Ran into this today as well, as a workaround I've simply added this as an npm posttest command "posttest" : "taskkill /FI "IMAGENAME eq 2.36-x64-chromedriver" /F" based on @rgustavsson suggestion. Would really like to see a fix from selnium's side though.

[phil-lgr]

I've been running this as a post npm script:

const shell = require('shelljs/shell.js');
shell.exec('taskkill /IM chromedriver.exe /F', {silent: true});
shell.exec('kill -9 $(pgrep chromedriver)', {silent: true});

[cuff-links]

I am having a similar issue. But I am also having the issue where the first test fails with the Connection Reset error. There were no lingering chromedriver sessions open. I run my tests and the first chrome test fails. This started all of a sudden too. I was having no failures and now it just keeps failing.

[cuff-links]

Works fine against saucelabs because each test is run on its own machine. It's only when I run these locally.

[phil-lgr]

@silne30 maybe check https://github.com/webdriverio/wdio-selenium-standalone-service/issues/39

[ichipev]

Hi guys. I was trying to find most proper workaround for that issue for last couple of days. So far adding a script with taskkill /IM "chromedriver*" /F is good one but it will kill all drivers, which means you can't run more than 1 test instance at same time, since this will kill all chromedrivers. It is good way if you don't need to run 2 instance simultaneously. So far best workaround for me was to use afterAll with browser.driver.quit(), unfortunately after some updates afterAll stopped working and I made it as a method that I've put at the end of every test. There is an error but at least works and it doesn't affects the test's results

[rycornell]

I've tried all of the suggestions mentioned above and received inconsistent results. The only way I've gotten it to work consistently is by adding these lines to wdio.conf.js:

afterSession: function(){
    // workaround to make sure the chromedriver shuts down
    browser.end().pause(1000);
},
after: function(){
    // workaround to make sure the chromedriver shuts down
    browser.pause(1000);
}

I don't have a good explanation. Putting browser.end().pause(1000) in the after didn't work. Also tried with only the afterSession code and it didn't work.