Rcutils: Add environment variable to configure logging level

Created on 18 Jun 2019  ·  7Comments  ·  Source: ros2/rcutils

Today I tried to debug my ROS2 setup, but I was unable to get detailed logging output. It would be good to be able to set the default log level via an environment variable.

My idea would be to be able to do this:

  • export RCUTILS_LOG_LEVEL=DEBUG
  • run executable with more debug output than normally the case.

Is this a good idea? Or did I miss some other option to troubleshoot my setup?

Most helpful comment

I'll take a look at this then and try to get a first-pass PR up in the next week.

All 7 comments

There are several ways to increase the logging levels in ROS 2. There is a concept page and a tutorial page .

I'm going to close this out, but if you feel that those aren't sufficient, feel free to keep commenting, reopen, or ideally provide a PR to https://github.com/ros2/ros2_documentation to improve the documentation.

@clalancette , per the link cited, is there a ticket tracking external configuration of loggers at runtime?

In the future there will be a generalized approach to external configuration of loggers at runtime (similar to how rqt_logger_level in ROS 1 allows logger configuration via remote procedural calls). This concept is not yet officially supported in ROS 2. In the meantime, this demo provides an example service that can be called externally to request configuration of logger levels for known names of loggers in the process.
https://docs.ros.org/en/foxy/Tutorials/Logging-and-logger-configuration.html#logger-level-configuration-externally

I'd like to set the log level for an entire launch file without modifying the third party package it belongs to.

Is anyone currently working on these? If not, I'll take a look at them.

Is anyone currently working on these? If not, I'll take a look at them.

Not that I know of.

If you are interested in this, we'd welcome the help. In that case, I'll suggest starting with https://github.com/ros2/design/issues/314 , and coming up with a design document that describes what we want the logging subsystem to be. From there, we can determine what pieces we have and what is missing. With all of that information in hand, we can then move forward with implementing the remaining pieces.

I'll take a look at this then and try to get a first-pass PR up in the next week.

Was this page helpful?
0 / 5 - 0 ratings