ROS2: rviz in docker container

asked 2018-08-20 15:11:53 -0500

alsora
1322 ●45 ●83 ●76 https://github.com/alsora

updated 2018-08-20 20:08:51 -0500

jayess
6155 ●26 ●85 ●92

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

Comments

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.

ruffsl ( 2018-08-20 16:10:05 -0500 )edit

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.

ruffsl ( 2018-08-20 16:31:06 -0500 )edit

add a comment

answered 2018-08-20 16:22:20 -0500

ruffsl
1094 ●19 ●44 ●40

updated 2018-08-20 16:27:56 -0500

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/...

edit flag offensive delete link

Comments

@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 --privilegedflag. 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/+so... , but we're on a much newer version of docker now (19.03.8)

jbinney ( 2020-05-11 17:06:46 -0500 )edit

Update: i managed to workaround the problem by downloading the newest docker seccomp config from https://raw.githubusercontent.com/mob... and passing it to "docker run" using " --security-opt seccomp=/path/to/config.json". See https://docs.docker.com/engine/securi...

This seems preferable to running with "--privilieged"

jbinney ( 2020-05-11 18:48:06 -0500 )edit

Update to the update: i was wrong... that didn't fix it.

jbinney ( 2020-05-11 19:50:46 -0500 )edit

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/3...

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.

jbinney ( 2020-05-12 01:02:45 -0500 )edit

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?

ruffsl ( 2020-05-14 00:54:40 -0500 )edit

@ruffsl i haven't tried 20.04 yet - I'll update this issue when i do (might be a while)

jbinney ( 2020-05-14 17:22:09 -0500 )edit

@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

tfoote ( 2020-05-14 17:36:11 -0500 )edit

@jbinney repeated all you step to start the container, still same error exist. I am using a non-root user (id 1000).

ThomasL624 ( 2022-11-28 22:11:39 -0500 )edit

add a comment

ROS2: rviz in docker container

Comments

1 Answer

Dockerfile

run.bash

terminal

Comments

Question Tools

Stats

Related questions

ROS2: rviz in docker container edit

Comments

1 Answer

Dockerfile

run.bash

terminal

Comments

Question Tools

Stats

Related questions

ROS2: rviz in docker container