WebDriverException: unknown error: DevToolsActivePort file doesn't exist while trying to initiate Chrome Browser WebDriverException: unknown error: DevToolsActivePort file doesn't exist while trying to initiate Chrome Browser google-chrome google-chrome

WebDriverException: unknown error: DevToolsActivePort file doesn't exist while trying to initiate Chrome Browser


Thumb rule

A common cause for Chrome to crash during startup is running Chrome as root user (administrator) on Linux. While it is possible to work around this issue by passing --no-sandbox flag when creating your WebDriver session, such a configuration is unsupported and highly discouraged. You need to configure your environment to run Chrome as a regular user instead.


This error message...

org.openqa.selenium.WebDriverException: unknown error: DevToolsActivePort file doesn't exist 

...implies that the ChromeDriver was unable to initiate/spawn a new WebBrowser i.e. Chrome Browser session.

Your code trials and the versioning information of all the binaries would have given us some hint about what's going wrong.

However as per Add --disable-dev-shm-usage to default launch flags seems adding the argument --disable-dev-shm-usage will temporary solve the issue.

If you desire to initiate/span a new Chrome Browser session you can use the following solution:

System.setProperty("webdriver.chrome.driver", "C:\\path\\to\\chromedriver.exe");ChromeOptions options = new ChromeOptions();options.addArguments("start-maximized"); // open Browser in maximized modeoptions.addArguments("disable-infobars"); // disabling infobarsoptions.addArguments("--disable-extensions"); // disabling extensionsoptions.addArguments("--disable-gpu"); // applicable to windows os onlyoptions.addArguments("--disable-dev-shm-usage"); // overcome limited resource problemsoptions.addArguments("--no-sandbox"); // Bypass OS security modelWebDriver driver = new ChromeDriver(options);driver.get("https://google.com");

disable-dev-shm-usage

As per base_switches.cc disable-dev-shm-usage seems to be valid only on Linux OS:

#if defined(OS_LINUX) && !defined(OS_CHROMEOS)// The /dev/shm partition is too small in certain VM environments, causing// Chrome to fail or crash (see http://crbug.com/715363). Use this flag to// work-around this issue (a temporary directory will always be used to create// anonymous shared memory files).const char kDisableDevShmUsage[] = "disable-dev-shm-usage";#endif

In the discussion Add an option to use /tmp instead of /dev/shm David mentions:

I think it would depend on how are /dev/shm and /tmp mounted.If they are both mounted as tmpfs I'm assuming there won't be any difference.if for some reason /tmp is not mapped as tmpfs (and I think is mapped as tmpfs by default by systemd), chrome shared memory management always maps files into memory when creating an anonymous shared files, so even in that case shouldn't be much difference. I guess you could force telemetry tests with the flag enabled and see how it goes.

As for why not use by default, it was a pushed back by the shared memory team, I guess it makes sense it should be useing /dev/shm for shared memory by default.

Ultimately all this should be moving to use memfd_create, but I don't think that's going to happen any time soon, since it will require refactoring Chrome memory management significantly.


Reference

You can find a couple of detailed discussions in:


Outro

Here is the link to the Sandbox story.


I started seeing this problem on Monday 2018-06-04. Our tests run each weekday. It appears that the only thing that changed was the google-chrome version (which had been updated to current) JVM and Selenium were recent versions on Linux box ( Java 1.8.0_151, selenium 3.12.0, google-chrome 67.0.3396.62, and xvfb-run).
Specifically adding the arguments "--no-sandbox" and "--disable-dev-shm-usage" stopped the error. I'll look into these issues to find more info about the effect, and other questions as in what triggered google-chrome to update.

ChromeOptions options = new ChromeOptions();        ...        options.addArguments("--no-sandbox");        options.addArguments("--disable-dev-shm-usage");


We were having the same issues on our jenkins slaves (linux machine) and tried all the options above.

The only thing helped is setting the argument

chrome_options.add_argument('--headless')

But when we investigated further, noticed that XVFB screen doesn't started property and thats causing this error. After we fix XVFB screen, it resolved the issue.