ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

sudo usage in rosdistro packages



I’m currently working on a dependency bug checker that runs on ROS packages and tries to detect missing dependencies.
I’ve detected a few bugs in bash scripts in packages where a dependency run in the script is not specified as exec/run_depends in package.xml files.
I verify every parsed command against a list of default commands available in a base ROS distribution, which leads me to my question regarding best practices in bash scripts in ROS:

On various internet sites (ie. sudo should never be used inside scripts, but scripts should instead be run using sudo and commands in the script can then be assumed to run with elevated privileges. I detect a lot of sudo’ing which I have labelled as an error so far, mainly due to sudo not also not being available when running packages in the official docker ROS image, which makes every single package with sudo in shell scripts error out when running ROS in docker.

My question is then:

  • What is the best practices regarding using sudo in bash scripts contained in a ROS package?

Thanks for any answers in advance.


I don’t know the use cases you may be finding for sudo to be needed. Could you give a few examples? It may be easier to reason and maybe create these best practices.

The only reference to best practices I found is here: (linked from

  • Don’t use sudo in wrapper packages.
  • Don’t require manual system wide installations.


I have scanned the source of all packages found in the distribution.yaml found in the rosdistro GitHub repository.

The following scripts contain sudo:


Those scripts seem to mainly do:

  1. Add/delete udev rules
  2. Create/Start/Stop a daemon
  3. Create user/deal with a database (postgresql)
  4. Using tcpdump (for velodyne)

For 1) Hmm I don’t know how the ROS packaging works so to know if we can have a standard way of doing this from a ROS package straight from the CMakeLlists.txt
For 2) & 4) I guess that is more of a manual step?
For 3) it could be either asked to be done manually or (as I found here) use a local database.


A compromise could be to add a check if already running with super user rights to the scripts, something like

if [[ $EUID -ne 0 ]]; then

$SUDO command


Just wanted to point out this answer by Mike Purvis about how udev rules may/should be installed by packages. Not sure this directly translates to packages being built/installed locally, though.


Nice, I didn’t know about that!

When installing a package from source, the udev rules have to be installed manually. It turns out that kobuki_ftdi uses the technique you mentioned above to install the udev rules from the binary package, and the create_udev_rules script is provided for users that build from source.

To come back to the original question by @andersfischer: I would label sudo in scripts as a warning, not an error. There are instances where sudo inside a script would be very bad (e.g., when that script is executed from the CMakeLists), and I can’t think of a case where it cannot be avoided, but in some instances it’s relatively harmless.


Thanks for the answer! :+1: