Skip to content
Selenium WebDriver · error message

Selenium: Chrome failed to start: DevToolsActivePort file doesn't exist

ConfigurationDrivers & browser start-up

Last verified

The exact message
selenium.common.exceptions.SessionNotCreatedException: Message: session not created: Chrome failed to start: exited abnormally. (unknown error: DevToolsActivePort file doesn't exist) (The process started from chrome location /usr/bin/google-chrome is no longer running, so ChromeDriver is assuming that Chrome has crashed.); For documentation on this error, please visit: https://www.selenium.dev/documentation/webdriver/troubleshooting/errors#sessionnotcreatedexception

What it means

ChromeDriver launched Chrome and waited for it to write a small file announcing its DevTools port. Chrome exited, or never got far enough to write it, so ChromeDriver gave up. The DevToolsActivePort file itself is not the problem; its absence is just how ChromeDriver notices that Chrome did not start. Depending on the ChromeDriver version the exception class may be SessionNotCreatedException or WebDriverException, and the first line may say exited abnormally or exited normally.

On Linux servers and in Docker, the usual reasons are running as root without --no-sandbox, a tiny /dev/shm, missing display for a non-headless run, or a user data directory that is already in use by another Chrome. On desktops it is often a profile directory locked by an open Chrome window.

What is not wrong: the driver version, if versions match. Mismatches produce a different message.

What it looks like

from selenium import webdriver

options = webdriver.ChromeOptions()
options.add_argument("--headless=new")
options.add_argument("--disable-dev-shm-usage")
options.add_argument("--window-size=1366,900")
# Only when running as root in an isolated container:
# options.add_argument("--no-sandbox")
driver = webdriver.Chrome(options=options)

Why it happens

  • Running Chrome as root in a container without --no-sandbox.
  • Docker's default 64 MB /dev/shm is too small and Chrome crashes on start.
  • Launching headed Chrome on a server with no display.
  • --user-data-dir points to a profile already open in another Chrome process.
  • Missing system libraries or an incompatible Chrome binary for the platform.

How to fix it

  1. Run headless on servers: options.add_argument('--headless=new').
  2. In containers, add --disable-dev-shm-usage or start the container with --shm-size=2g.
  3. Run as a non-root user; if impossible and content is trusted, add --no-sandbox.
  4. Use a fresh or dedicated --user-data-dir that no other Chrome is using.
  5. Start Chrome manually with the same flags (google-chrome --headless=new --dump-dom https://example.com) to see its own error output.

How to stop it recurring

Use a container image built for browser automation, such as the official selenium/standalone-chrome image, or give Chrome adequate shared memory and a non-root user. Keep automation profiles separate from personal Chrome profiles. Enable ChromeDriver verbose logging in CI so start-up crashes leave a trail.

Official documentation: developer.chrome.com/docs/chromedriver/help/chrome-doesnt-start. See all Selenium error messages.

Related errors

Definitions

Quick answers

What does "Chrome failed to start: DevToolsActivePort file doesn't exist" mean in Selenium?

ChromeDriver launched Chrome and waited for it to write a small file announcing its DevTools port. Chrome exited, or never got far enough to write it, so ChromeDriver gave up. The DevToolsActivePort file itself is not the problem; its absence is just how ChromeDriver notices that Chrome did not start.

How do I fix "Chrome failed to start: DevToolsActivePort file doesn't exist"?

1. Run headless on servers: options.add_argument('--headless=new'). 2. In containers, add --disable-dev-shm-usage or start the container with --shm-size=2g. 3. Run as a non-root user; if impossible and content is trusted, add --no-sandbox. 4. Use a fresh or dedicated --user-data-dir that no other Chrome is using. 5. Start Chrome manually with the same flags (google-chrome --headless=new --dump-dom https://example.com) to see its own error output.

Run browser automation you can watch and take over

Autonoly runs each job in a real cloud Chromium browser driven by Playwright. Timeouts and detached elements still happen; the difference is that you can watch the run live, see the step that failed, and take control of the browser to finish it.

Also see Live browser control.