[🐛 Bug]: standalone-chromium not working in non-headless from version 110 onwards

[corderop]

What happened?

I have been facing problems when trying to use non-headless mode with the newest versions of the containers. The headless mode was working fine, but the non-headless generated the error specified bellow.

I started to try with different versions of the container and noticed that this is happening from version 110.0 onwards (109.0 is working fine for me)

Command used to start Selenium Grid with Docker

docker pull seleniarm/standalone-chromium:110.0

Relevant log output

SessionNotCreatedException: Message: Could not start a new session. Error while creating session with the driver service. Stopping driver service: Could not start a new session. Response code 500. Message: unknown error: Chrome failed to start: crashed.
  (unknown error: DevToolsActivePort file doesn't exist)
  (The process started from chrome location /usr/bin/chromium is no longer running, so ChromeDriver is assuming that Chrome has crashed.) 
Host info: host: '7e67c4ca2f6d', ip: '172.21.0.7'
Build info: version: '4.8.1', revision: '8ebccac989'
System info: os.name: 'Linux', os.arch: 'aarch64', os.version: '5.15.49-linuxkit', java.version: '11.0.18'
Driver info: driver.version: unknown
Build info: version: '4.8.1', revision: '8ebccac989'
System info: os.name: 'Linux', os.arch: 'aarch64', os.version: '5.15.49-linuxkit', java.version: '11.0.18'
Driver info: driver.version: unknown
Stacktrace:
    at org.openqa.selenium.grid.node.config.DriverServiceSessionFactory.apply (DriverServiceSessionFactory.java:202)
    at org.openqa.selenium.grid.node.config.DriverServiceSessionFactory.apply (DriverServiceSessionFactory.java:69)
    at org.openqa.selenium.grid.node.local.SessionSlot.apply (SessionSlot.java:147)
    at org.openqa.selenium.grid.node.local.LocalNode.newSession (LocalNode.java:384)
    at org.openqa.selenium.grid.distributor.local.LocalDistributor.startSession (LocalDistributor.java:645)
    at org.openqa.selenium.grid.distributor.local.LocalDistributor.newSession (LocalDistributor.java:564)
    at org.openqa.selenium.grid.distributor.local.LocalDistributor$NewSessionRunnable.handleNewSessionRequest (LocalDistributor.java:818)
    at org.openqa.selenium.grid.distributor.local.LocalDistributor$NewSessionRunnable.lambda$run$1 (LocalDistributor.java:779)
    at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628)
    at java.lang.Thread.run (Thread.java:829)

Operating System

macOS Ventura 13.4 (M1)

Docker Selenium version (tag)

110.0

[jamesmortensen]

Hi @corderop can you please provide a small sample test and the command to execute it, which replicates the issue? Thank you!

[corderop]

I have been debugging this a little bit more, and the problem appears when the USER is changed in the Dockerfile

FROM seleniarm/standalone-chromium:{version}
USER root
RUN groupadd -r second_user \
  && useradd -r -g second_user second_user
USER second_user

  selenium:
    build:
      context: .
      dockerfile: ./Dockerfile
    ports:
      - '4444:4444'
      - '7900:7900'

from selenium import webdriver

options = webdriver.ChromeOptions()
options.headless = False

driver = webdriver.Remote("http://localhost:4444/wd/hub", desired_capabilities=options.to_capabilities())
driver.get("https://www.google.com")
driver.quit()

The issue appears if the version specified in the Dockerfile is higher than 110. Everything worked fine for 109.0.

In my case, I managed to solve the problem by removing the use of the second_user because it was an old code no longer needed in my case, but I report it here in case this needs to be fixed.

[jamesmortensen]

Thanks for the info @corderop I don't know if there is a valid use case for changing the user. All of the permissions are set to the seluser (user 1200) with the expectation that this user would be the one to launch all of the resources. Moreover, since you're not relying on using an additional user, I think we can go ahead and close this issue as resolved.

Thanks again for circling back around!

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.