Selenium::WebDriver::Error::SessionNotCreatedError, session not created: probably user data directory is already in use

[db-lyon]

I've been stuck on this error message for over a week now when trying to run a robot framework script (selenium) on heroku.

session not created: probably user data directory is already in use, please specify a unique value for --user-data-dir argument, or don't use --user-data-dir

My solution works fine as-is in every context except heroku.

I've tried including arguments like headless, incognito, no-sandbox.

I've tried creating my own arbitrary directories like tmp/user-data-dir-{timestamp}.

I've tried setting it to null, empty string, and omitting it entirely.

I honestly can't make heads or tails of this and it feels like no matter what options I apply, heroku just entirely ignores them or insta-locks any temp directories I make.

Happy to provide more information.

[mars]

There's nothing Heroku does to the filesystem at dyno runtime, so I'd suggest ensuring that the directory really is created before the Selenium script runs with the access required.

Try creating the directory in the dyno before the script tries to access it within the user workspace /app, like mkdir -p /app/tmp/<unique-random>, and ensure that the current user has full access chmod 700 /app/tmp/<unique-random>.

[duc-codecomplete]

Selenium::WebDriver::Error::SessionNotCreatedError: session not created: probably user data directory is already in use, please specify a unique value for --user-data-dir argument, or don't use --user-data-dir

The same issue...

[mars]

We've yet to see this error in our own Ruby/Capybara setup. Looking up what that --user-data-dir does, it seems to be for selecting a sandboxed profile. So, wondering if Chrome sandboxing is actually the culprit here.

This buildpack's README mentions…

If the app fails to start Chrome, please ensure that the following argument flags are set wherever chrome is invoked:

--headless
--no-sandbox

Some use-cases may require these flags too:

--disable-gpu
--remote-debugging-port=9222

Please try adding the --headless & --no-sandbox flags to the Chrome invocation, and let us know if that solves the problem 🙏

[mars]

Found some common issues opened about this too:
SeleniumHQ/selenium#15340
SeleniumHQ/selenium#15327
https://issues.chromium.org/issues/399391549

[yash-learner]

For me, changing from the old to new headless option fixed this error, options.add_argument("--headless=new") in a rails app 🤷‍♂️

ps: I am using GitHub CI & locally

[mars]

We just found that this was caused in a Ruby on Rails app because of something conflicting or broken with Rails' built-in System Testing. In our case, switched to use Capybara/rspec explicitly, and not Rails' builtin thingy.

[db-lyon]

@mars interesting! I'll give that a try

[baterja]

We had a similar issue, and it occurred that the root cause was trying to run non-headless Chrome in a desktop-less environment. The real problem was discovered when chromeDriverService.EnableVerboseLogging = true; was set, and we looked at the standard output (not test output).

[ameft]

I've started to see this same issue last week in my heroku app after a very simple update not related to Selenium. I've tried multiple fixes (including --headless=new) but nothing worked. Previously everything worked well for weeks. I use Selenium not for testing but for complex web scraping.
EDIT: I've just realized that the issue presented itself after the stable version of Chrome went from v134 to v135. I don't know if it's just a coincidence.

[edminshull]

@ameft Seem you're on to something with this I was hitting issue with chromium v135 but now all is good with v124

[ameft]

@ameft Seem you're on to something with this I was hitting issue with chromium v135 but now all is good with v124

@edminshull how can you downgrade your Chrome version on Heroku? I hoped that the this buildpack allows you to specify the Chrome version but it seems impossible.