ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

running node as root successful with su rosrun but fails to connect with master with sudo tag in launch

asked 2017-05-04 19:00:28 -0500

Corusco gravatar image

Hi all,

As indicated, I have a particular node I would like to run with root to interface with some GPIO hardware. I'm aware of the recommendations against running anything as root and also recommendations to export the pin, etc. I'm running my ROS environment on an Odroid, using the canonical GPIO library WiringPi to access the pins, and the provider of WiringPi has fairly definitively stated the pins on the odroid cannot be exported; we must run as root.

I have followed the template as posed here: by setting up passwordless sudo. I've also set up the ROS environment variables for the root user. When I have all other nodes running, I can launch my node as root user (no other setup preamble) in one terminal and interface with it in another terminal, and all works as expected. I should also mention we run a startup script at load to source the necessary files and run the roslaunch file. All nodes should be present without user input after startup has finished.

When launching with roslaunch and the launch_prefixtag, however, I get an error stating the ROS_MASTER_URI is not defined in the environment. Also in the error is suggestion to add export ROS_MASTER_URI=http://localhost:11311 to the .bashrc. I've done this for my standard user .bashrc, but I still get the error and the node process dies.

Would definitely appreciate some guidance or opinion.

Thanks very much!

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2019-09-13 00:02:40 -0500

jared gravatar image

I know this is an old question - but I ran into the same thing today, so figured I'd add a solution.

Adding -E to the launch prefix to preserve the environment worked for me:

launch-prefix="sudo -E"

From the sudo manual:

The -E (preserve environment) option indicates to the security policy that the user wishes to preserve their existing environment variables. The security policy may return an error if the -E option is specified and the user does not have permission to preserve the environment.

As @ahendrix says in his answer here:

Note that both of these methods will unset LD_LIBRARY_PATH before executing your node (it's a security feature of glibc). This means that your node will either need to be statically compiled, or you'll need to turn on RPATH during the compilation process, so that the library search path is included in your executable rather than relying on the environment to be set up correctly.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2017-05-04 19:00:28 -0500

Seen: 1,302 times

Last updated: Sep 13 '19