-
Notifications
You must be signed in to change notification settings - Fork 765
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Running discovery process as root breaks existing processes running as normal user when SHM is used #3475
Comments
Hi @ksuszka, thanks for the report. |
I have also encountered this issue. For me it works to:
For convenience, I have created this repository with my setup to build (as root user) and run (with host's user id) ROS 2 packages/ nodes inside containers. This allows to use Shared Memory Transport (SHM) between ROS 2 nodes run inside the container and on the host. |
Is there an already existing issue for this?
Expected behavior
Running an arbitrary ROS command as a root should not break existing ROS ecosystem running under a non-root user.
Current behavior
Running an arbitrary ROS command under SHM transport as a root breaks service discovery for ROS nodes running as a non-root user.
Steps to reproduce
Open four terminals. In the first terminal, start publishing messages as a non-root user:
docker run -it --net=host --privileged --ipc=host -u 5678 -e HOME=/tmp ros:humble ros2 topic pub /foo std_msgs/msg/String "data: foo"
In the second terminal, start a process to retrieve messages as as the same non-root user
You should see proper output, as expected.
In the third terminal, run some ROS command as a root:
You should see
WARNING: topic [/foo] does not appear to be published yet
- it is not preferable, but can be explained by other issues like #2624 (comment)In the fourth terminal, run the same command as in the second step:
This time, you will see
WARNING: topic [/foo] does not appear to be published yet
.The previous command broke discovery of existing nodes.
Fast DDS version/commit
ros-humble-fastrtps-cmake-module/now 2.2.0-2jammy.20230112.142430 amd64 [installed,local]
ros-humble-fastrtps/now 2.6.4-1jammy.20230117.223829 amd64 [installed,local]
ros-humble-rmw-fastrtps-cpp/now 6.2.2-1jammy.20230117.225910 amd64 [installed,local]
ros-humble-rmw-fastrtps-shared-cpp/now 6.2.2-1jammy.20230117.225455 amd64 [installed,local]
ros-humble-rosidl-typesupport-fastrtps-c/now 2.2.0-2jammy.20230112.145514 amd64 [installed,local]
ros-humble-rosidl-typesupport-fastrtps-cpp/now 2.2.0-2jammy.20230112.145146 amd64 [installed,local]
Platform/Architecture
Other. Please specify in Additional context section.
Transport layer
Default configuration, UDPv4 & SHM
Additional context
This is yet another issue related to the shared memory transport in FastDDS (other related issues I found: ros2/ros2cli#598, #1750, #2624). However this experiment shows that the issue occurs not only when new connections between different users are established but can affect the service discovery for a single user.
XML configuration file
No response
Relevant log output
No response
Network traffic capture
No response
The text was updated successfully, but these errors were encountered: