ROS2: rviz in docker container

Question

Hi,

I'm trying to use Rviz2 from within a Docker container.

I'm working on top of this Docker image

FROM osrf/ros2:bouncy-desktop

This is my run script

#!/bin/bash

XSOCK=/tmp/.X11-unix
XAUTH=/tmp/.docker.xauth

touch $XAUTH

xauth nlist $DISPLAY | sed -e 's/^..../ffff/' | xauth -f $XAUTH nmerge -

docker run -it --rm \
 -e XAUTHORITY=${XAUTH} \
 -e DISPLAY=$DISPLAY \
 -e QT_GRAPHICSSYSTEM=native \
 -v $XSOCK:$XSOCK:rw \
 -v $XAUTH:$XAUTH:rw \
 ros2_docker \
 bash

Everything works fine, but then I needed to make the Docker container communicate with other machines on the host network. I accomplished that by adding the following option to docker run --net=host \

This solves the connectivity issue, but has the side effect of making rviz not working anymore. If I try to run rviz, I only get the following error.

 ros2 run rviz2 rviz2

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
dbus[1041]: The last reference on a connection was dropped without closing the connection. This is a bug in an application. See dbus_connection_unref() documentation for details.
Most likely, the application was supposed to call dbus_connection_close(), since this is a private connection.
  D-Bus not built with -rdynamic so unable to print a backtrace

Any idea about how to fix this? Thanks

---

Originally posted by alsora on ROS Answers with karma: 1322 on 2018-08-20

Post score: 4

---

Original comments

Comment by ruffsl on 2018-08-20:
That's peculiar. I'm using nvidia docker, yet I can reproduce your rviz(1 or 2) XDG_RUNTIME_DIR error when adding --net=host for both melodic and bouncy images.

Comment by ruffsl on 2018-08-20:
XDG_RUNTIME_DIR doesn't seem to be necessary the issue, given it otherwise would normally default to something like '/tmp/runtime-root'. The privilege issue with managing the dbus connection seem to be the setback here.

Answer 1

I'm not yet totally sure yet as to why, but it appears that using the host network driver then necessitates adding the privileged flag if one also wishes to use the host's X11 unix socket simultaneously. I.e. just add --privileged upon using --net=host with the docker run command when expecting to forward containerised GUIs to the host's X11 display.

A small example I used to check this:

Dockerfile

FROM osrf/ros2:bouncy-desktop

# nvidia-container-runtime
ENV NVIDIA_VISIBLE_DEVICES \
    ${NVIDIA_VISIBLE_DEVICES:-all}
ENV NVIDIA_DRIVER_CAPABILITIES \
    ${NVIDIA_DRIVER_CAPABILITIES:+$NVIDIA_DRIVER_CAPABILITIES,}graphics

run.bash

#!/bin/bash

XSOCK=/tmp/.X11-unix

docker run -it --rm \
 --runtime=nvidia \
 -e DISPLAY=$DISPLAY \
 -v $XSOCK:$XSOCK \
 -v $HOME/.Xauthority:/root/.Xauthority \
 --privileged \
 --net=host \
 osrf/ros2:bouncy-desktop-nvidia "$@"

terminal

docker build -t osrf/ros2:bouncy-desktop-nvidia .
bash run.bash ros2 run rviz2 rviz2

Note that if you're not using nvidia, you can use intel's embedded graphics just as well instead:
http://wiki.ros.org/docker/Tutorials/Hardware%20Acceleration#Intel

---

Originally posted by ruffsl with karma: 1094 on 2018-08-20

This answer was ACCEPTED on the original site

Post score: 11

---

Original comments

Comment by jbinney on 2020-05-11:
@ruffsl - did you ever figure out why --privileged was needed in this case? We use --net=host and we see gazebo, rviz, and rqt fail with that same dbus error message unless we use the --privileged flag. I'd like to avoid running containers in privileged mode if at all possible, but i haven't yet found another workaround. This feels potentially related to https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1774739 , but we're on a much newer version of docker now (19.03.8)

Comment by jbinney on 2020-05-11:
Update: i managed to workaround the problem by downloading the newest docker seccomp config from https://raw.githubusercontent.com/moby/moby/master/profiles/seccomp/default.json and passing it to "docker run" using " --security-opt seccomp=/path/to/config.json". See https://docs.docker.com/engine/security/seccomp/

This seems preferable to running with "--privilieged"

Comment by jbinney on 2020-05-11:
Update to the update: i was wrong... that didn't fix it.

Comment by jbinney on 2020-05-12:
Ah! It was (at least for me) a problem with the default apparmor profile blocking that dbus call. Adding "--security-opt apparmor:unconfined" works, and seems better than "--privileged". This seems to be the issue: https://github.com/moby/moby/issues/38442

Hopefully docker/apparmor and qt sync up on this in 20.04 so that the default apparmor profile allows running QT apps in docker more easily.

Comment by ruffsl on 2020-05-14:
Wow, that's a deep rabbit hole. Still looks like a pain to patch and document everyware. Is this still needed for Ubuntu 20.04, or have you not gotten around to trying it out on the latest distro?

Comment by jbinney on 2020-05-14:
@ruffsl i haven't tried 20.04 yet - I'll update this issue when i do (might be a while)

Comment by tfoote on 2020-05-14:
@jbinney, what are you running as the host. I can run rocker --nvidia --x11 --network host osrf/ros2:nightly 'bash -c ". /opt/ros/foxy/setup.bash && rviz2"' successfully

which runs docker run -it --rm --network host --gpus all -e DISPLAY -e TERM -e QT_X11_NO_MITSHM=1 -e XAUTHORITY=/tmp/.docker.xauth -v /tmp/.docker.xauth:/tmp/.docker.xauth -v /tmp/.X11-unix:/tmp/.X11-unix -v /etc/localtime:/etc/localtime:ro cdfc90f87eb4 bash -c ". /opt/ros/foxy/setup.bash && rviz2"

With a host of 18.04

Comment by ThomasL624 on 2022-11-28:
@jbinney repeated all you step to start the container, still same error exist. I am using a non-root user (id 1000).