Discovery fails if daemon is started as root

[ksuszka]

Bug report

Required Info:

• Operating System: Ubuntu 20.04
• Installation type: official foxy docker image
• Version or commit hash:
• DDS implementation: rmw_fastrtps_cpp
• Client library (if applicable):

Steps to reproduce issue

Open two terminal sessions. In the first terminal run:
$ docker run -it --rm --name test ros:foxy
root@f536811845fe:/# apt update -y && apt upgrade -y
...
root@f536811845fe:/# useradd test -m
root@f536811845fe:/# sudo -u test bash
test@f536811845fe:/$  . /opt/ros/foxy/setup.bash
test@f536811845fe:/$ ros2 topic pub /test std_msgs/String "data: Hello"
publisher: beginning loop
publishing #1: std_msgs.msg.String(data='Hello')
...

In second terminal run:
$ docker exec -it test bash
root@f536811845fe:/# . /opt/ros/foxy/setup.bash
root@f536811845fe:/# ros2 topic list
/parameter_events
/rosout

Expected behavior

Topic /test should be visible on topic list

Actual behavior

Topic /test is not present.

Additional information

Even after stopping root-owned _ros2_daemon and starting a new one as "test" user, topics in existing nodes are not discovered.

This issue only appears when ros packages are upgraded to the latest version from apt repository.

[ksuszka]

Small update. I had previous ros:foxy image on my machine. I've updated to the latest version. Now this issue occurs always as the latest packages are already installed in this image.

[fujitatomoya]

@ksuszka

thanks for the issue, i confirmed the problem with ros:foxy docker image.

and i also confirmed that this does not happen with ros:rolling, could you check the image named ros:rolling?

• rmw_cyclonedds

>docker run -it --rm --name test ros:rolling

[Terminal-1]
root@3c22425b7070:/# apt update -y && apt upgrade -y
...<snip>
root@3c22425b7070:/# useradd test -m
root@3c22425b7070:/# sudo -u test bash
test@3c22425b7070:/$  . /opt/ros/rolling/setup.bash
test@3c22425b7070:/$ ros2 topic pub /test std_msgs/String "data: Hello"
...

[Terminal-2]
root@3c22425b7070:/# . /opt/ros/rolling/setup.bash
root@3c22425b7070:/# ros2 topic list
/parameter_events
/rosout
/test
root@3c22425b7070:/# ros2 topic echo /test
data: Hello
---
data: Hello
---
...<snip>

• rmw_fastrtps

>docker run -it --rm --name test ros:rolling

[Terminal-1]
root@3c22425b7070:/# apt update -y && apt upgrade -y
...<snip>
root@3c22425b7070:/# useradd test -m
root@3c22425b7070:/# sudo -u test bash
test@3c22425b7070:/$  . /opt/ros/rolling/setup.bash
test@3c22425b7070:/$ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp
test@3c22425b7070:/$ ros2 topic pub /test std_msgs/String "data: Hello"
...

[Terminal-2]
root@3c22425b7070:/# . /opt/ros/rolling/setup.bash
root@3c22425b7070:/# export RMW_IMPLEMENTATION=rmw_fastrtps_cpp
root@3c22425b7070:/# ros2 topic list
/parameter_events
/rosout
/test
root@3c22425b7070:/# ros2 topic echo /test
data: Hello
---
data: Hello
---
...<snip>

[ksuszka]

Yep, I confirm that with rolling it is working as expected.

[ksuszka]

After more digging, it seems to work in the latest foxy image if I install and use rmw_cyclonedds_cpp.

Also I was able to digout in local docker cache some image built on top of ros:foxy image from two months ago, and it is working in that image and it stops working if I upgrade:

ros-foxy-fastrtps/focal 2.0.2-1focal.20201210.051121 amd64 [upgradable from: 2.0.1-1focal.20201006.191046]
ros-foxy-rmw-fastrtps-cpp/focal 1.2.4-1focal.20210125.204642 amd64 [upgradable from: 1.2.2-1focal.20201015.203910]
ros-foxy-rmw-fastrtps-shared-cpp/focal 1.2.4-1focal.20210125.203358 amd64 [upgradable from: 1.2.2-1focal.20201015.203537]

[fujitatomoya]

@ksuszka i am not sure which exact fix is related to this issue or introduced. but something you need is up-to-date ros:foxy image with rmw_fastrtps, right?

[ksuszka]

No, sorry, I probably wasn't clear. It was working in official ros:foxy image two months ago. This image had ros-foxy-fastrtps 2.0.1 and ros-foxy-rmw-fastrtps-cpp 1.2.2. It is not working in the latest image with ros-foxy-fastrtps 2.0.2 and ros-foxy-rmw-fastrtps-cpp 1.2.4. So it seems that the latest changes broke something.

[fujitatomoya]

https://github.com/eProsima/Fast-DDS/releases/tag/v2.0.2

CC: @MiguelCompany @IkerLuengo any thoughts?

[MiguelCompany]

Shared memory transport is active by default since Fast DDS v2.0.2, so I think this is related to eProsima/Fast-DDS#1750

We are currently developing a fix that should avoid this issue. It will basically detect the situation and fallback to UDP communication in that case.