0
$\begingroup$

Rosanswers logo

We often have problems with seeing topics from nodes started as super user. Sometimes we had this issue without sudo but I cannot reproduce it so I will focus on that point.

The easiest way for me to reproduce is starting the demo talker as super user:

open terminal -> sudo -s -> source /opt/ros/foxy/local_setup.sh -> ros2 run demo_nodes_cpp talker

Then open another terminal and source /opt/ros/foxy/local_setup.sh -> ros2 topic list

If I open the second terminal as super user I am able to see the chatter topic.

Is there anything I can do to make sure all nodes find each others topics on the same machine?

Edit: The reason my node has to run as root is we are capturing raw packages with pcap. That is also possible via specific capture capabilities but then you have issues with the path set by the setup scripts.

I tried to figure out what happens and after trying to show the ros2 topics as normal user the ros_daemon goes to 100% cpu load.

Edit2: The same issue arises when using different users where none is root but without the cpu load going up.


Originally posted by Sebastian Delling on ROS Answers with karma: 25 on 2021-04-12

Post score: 1


Original comments

Comment by gvdhoorn on 2021-04-14:
Perhaps an environment issue?

Did you set any env vars in the .bashrc of the non-root account? Perhaps a ROS domain ID?


Edit: and you probably already know this, but running ROS nodes (whether ROS 1 or ROS 2) as root is not a good idea. It's also not often really needed (device access fi under Linux can often be solved using appropriate user accounts and/or capabilities).

If you don't really need to run as root, it may save time trying to figure out what's going wrong by using a different approach.

Comment by Sebastian Delling on 2021-04-14:
Hi, we tried setting specific domain ids but that did not help. I will add some more information to my question.

Comment by gvdhoorn on 2021-04-14:
I'm inclined to suspect environmental factors, as running ROS 2 nodes in Docker containers works for many users. Without configuring it differently, everything in a Docker container runs as root.

Comment by gvdhoorn on 2021-04-14:\

Edit: The reason my node has to run as root is we are capturing raw packages with pcap. That is also possible via specific capture capabilities but then you have issues with the path set by the setup scripts.

what does "but then you have issues with the path set by the setup scripts" mean?

you mean that the environment is sanatised by loading the binary?

I've seen setups with a secondary process being given the required capabilities and then the ROS node communicating with that process using IPC or some other mechanism.

Separates concerns nicely, but I can understand why that would perhaps be involved.

Comment by Sebastian Delling on 2021-04-14:
Basically you cannot find the shared libraries of ROS because the path is reset. Here is a description of the issue: https://stackoverflow.com/questions/9843178/linux-capabilities-setcap-seems-to-disable-ld-library-path

Comment by gvdhoorn on 2021-04-14:
Yes, that's what I was referring to.

I tried to figure out what happens and after trying to show the ros2 topics as normal user the ros_daemon goes to 100% cpu load.

this seems like it could provide a clue.

Seeing as it's Python-based, you could see whether pdb can help finding out what's going on.

You could also try running it not as a background process, but in a separate terminal.

Comment by mcevoyandy on 2022-11-30:
@sebastian could you elaborate on how you changed the DDS settings? I'm facing the same issue but can't figure out how to force UDP like you mention below.

Comment by Sebastian Delling on 2022-12-01:
We ended up using cyclone DDS which uses UDP. See here. Also in this discussion there is the description how to use fastRTPS with UDP via a config file and the environment variable FASTRTPS_DEFAULT_PROFILES_FILE.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Edit2: The same issue arises when using different users where none is root but without the cpu load going up.

Which RMW are you using?

I remember a similar Q&A where it turned out that FastRTPS was trying to use shared memory between different users (as the processes were all running on the same machine) which didn't work, as those shared memory segments are not accessible by different users due to standard Linux security.

Note: using shared memory is obviously advantageous for performance, but in your setup it might not work due to external factors.


Edit: found it: #q371315. See the answer by @Iker (ie: the non-accepted answer).

Issue on the FastRTPS tracker: eProsima/Fast-DDS#1750.


Edit 2: and another related Q&A: #q370595.


Originally posted by gvdhoorn with karma: 86574 on 2021-04-14

This answer was ACCEPTED on the original site

Post score: 1


Original comments

Comment by Sebastian Delling on 2021-04-15:
Yes, thank you those links explained the issue and I was able to fix it via enforcing UDP with a fastRTPS config.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.