standalone-chrome-debug hangs because DBUS_SESSION_BUS_ADDRESS is lost with sudo

[Sovetnikov]

When selenium is started via "sudo -E -i seluser" on -debug standalone, DBUS_SESSION_BUS_ADDRESS=/dev/null variable is lost and chrome hangs periodically on startup.

Just test it:
root:# docker run --rm selenium/standalone-chrome-debug env | grep DBUS
DBUS_SESSION_BUS_ADDRESS=/dev/null
root:# docker run --rm selenium/standalone-chrome-debug sudo -E -i -u seluser env | grep DBUS

Please fix this in entry_point.sh by adding "sudo -E -i seluser DBUS_SESSION_BUS_ADDRESS=/dev/null"
It's very annoying bug.

https://github.com/SeleniumHQ/docker-selenium/blob/aabd14c0b8bebdef1e492ffde927b7815ee2b19a/StandaloneDebug/entry_point.sh

[a-k-g]

+1 for this issue. I was hitting #87 repeatedly even after the fix seemed to have been merged. Thanks @Sovetnikov for finding the root cause. I've made an attempt to fix this issue in #381.

[Sovetnikov]

6 months later this issue still exists

[diemol]

How can we reproduce it with the latest images @Sovetnikov?

Can you please provide a script that we can use?

[Sovetnikov]

As in initial issue description:
docker run --rm selenium/standalone-chrome-debug sudo -E -i -u seluser env | grep DBUS
or
docker run --rm selenium/standalone-chrome:3.4.0-dysprosium sudo -E -i -u seluser env | grep DBUS

Two weeks ago i made update to 3.4.0-dysprosium image and again getting timeouts on new selenium sessions.

[Sovetnikov]

3.1.0-astatine works fine:
docker run --rm selenium/standalone-chrome:3.1.0-astatine sudo -E -i -u seluser env | grep DBUS
seems DBUS fix is lost somewhere between 3.1 and 3.4

[Sovetnikov]

Two lines in custom Dockerfile fixed it for my:
RUN echo 'Defaults env_keep += "DBUS_SESSION_BUS_ADDRESS"' >> /etc/sudoers
RUN echo "DBUS_SESSION_BUS_ADDRESS=/dev/null" >> /etc/environment

[diemol]

If I do this: docker run --rm selenium/standalone-chrome:3.4.0-dysprosium sudo -E -i -u seluser env, I get this:

HOSTNAME=a301e6f6de32
TERM=unknown
SHELL=/bin/bash
USER=seluser
SUDO_USER=seluser
SUDO_UID=1000
USERNAME=seluser
MAIL=/var/mail/seluser
PATH=/home/seluser/bin:/home/seluser/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
PWD=/home/seluser
TZ=UTC
SHLVL=1
SUDO_COMMAND=/bin/bash -c env
HOME=/home/seluser
LOGNAME=seluser
SUDO_GID=1000
DISPLAY=:99.0
_=/usr/bin/env

But if I do this: docker run --rm selenium/standalone-chrome:3.4.0-dysprosium env (without the sudo and so on...), I get this:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=aec3922e49f2
DEBIAN_FRONTEND=noninteractive
DEBCONF_NONINTERACTIVE_SEEN=true
TZ=UTC
SCREEN_WIDTH=1360
SCREEN_HEIGHT=1020
SCREEN_DEPTH=24
DISPLAY=:99.0
NODE_MAX_INSTANCES=1
NODE_MAX_SESSION=1
NODE_PORT=5555
NODE_REGISTER_CYCLE=5000
NODE_POLLING=5000
NODE_UNREGISTER_IF_STILL_DOWN_AFTER=60000
NODE_DOWN_POLLING_LIMIT=2
NODE_APPLICATION_NAME=
DBUS_SESSION_BUS_ADDRESS=/dev/null
HOME=/home/seluser

The processes in the container are not running as root anymore, everything is running with seluser, maybe that's why you don't see the value with your command?

[Sovetnikov]

Can you see DBUS_SESSION_BUS_ADDRESS in your output? I'm not ... this is a problem
This command shows that DBUS_SESSION_BUS_ADDRESS is in env: docker run --rm selenium/standalone-chrome:3.1.0-astatine sudo -E -i -u seluser env | grep DBUS

But this command shows that DBUS_SESSION_BUS_ADDRESS is NOT in env anymore with latest docker image: docker run --rm selenium/standalone-chrome sudo -E -i -u seluser env | grep DBUS

About root... you can see that i'm aware of seluser and running test with sudo -u seluser

[diemol]

The DBUS_SESSION_BUS_ADDRESS is set in the base node image under the seluser user. That is why I can just do env in the container and then see it.

When I do sudo -E -i -u seluser env, I don't see it. My question is, why do you need to use that command to check the env vars? I was checking and we are not running any of the commands in the container with sudo.

What I see for all containers is that the DBUS_SESSION_BUS_ADDRESS is set and present in the seluser. A few people also tested it and we didn't hit the issue again.

That is why I was asking for a script (Selenium code running a test), that I could execute and reproduce the issue of getting timeouts when asking for a new session. Perhaps we need to improve something else.

[Sovetnikov]

This issue about debug image that runs selenium with sudo:
docker run --rm selenium/standalone-chrome-debug cat /opt/bin/entry_point.sh | grep sudo

Seems that initial issue was fixed in selenium/standalone-chrome image and it passed to debug image.
At now selenium/standalone-chrome has lost that fix and debug image as well.

[diemol]

I think I found the problem, but please help me check...

Try the same command you tried in the previous command, but using the tag 3.4.0-dysprosium.

I think we made a mistake when we put the tag to the most recent images. That is why you might see something different, I created #508

[Sovetnikov]

this command returns empty result on clean server without pulled earlier selenium images: docker run --rm selenium/standalone-chrome:3.4.0-dysprosium sudo -E -i -u seluser env | grep DBUS

[diemol]

@Sovetnikov, for that, I wrote this comment.

So, maybe you can help us to reproduce the issue as I mentioned in the last part of the comment?

That is why I was asking for a script (Selenium code running a test), that I could execute and reproduce the issue of getting timeouts when asking for a new session. Perhaps we need to improve something else.

[Sovetnikov]

Just read my first message about this issue, all as described there.
This bug was fixed, but fix is lost now.
This issue about selenium/standalone-chrome-debug image that runs selenium by sudo and then DBUS_SESSION_BUS_ADDRESS variable is lost.

Just add:
RUN echo 'Defaults env_keep += "DBUS_SESSION_BUS_ADDRESS"' >> /etc/sudoers
RUN echo "DBUS_SESSION_BUS_ADDRESS=/dev/null" >> /etc/environment
to Dockerfile of selenium/standalone-chrome-debug

[ddavison]

@Sovetnikov if you want, try your hand at a pull request and we'll review!