[Draft REP 0156:2026] `ros2log` Command Line Interface - Call for Discussion

ROS ROS Ideas
,
1

Hello ROS community! :waving_hand:

Following the REP-0001:2025 process, I’m opening this discussion thread for Draft REP 0156:2026: ROS Log Command Line Interface.

We are seeking community feedback on this REP, so please feel free to share your thoughts and opinion here.

Quick Links

Abstract

This REP proposes a new ros2log command-line package for ROS that provides a unified, user-friendly interface for runtime logging configuration and inspection.

Motivation

Currently, logging configuration from the command line in ROS 2 is limited or inconsistent. There is no central dedicated CLI for logging operations, which leads to:

  • Scattered approaches (ad-hoc subcommands or raw service calls)
  • Error-prone workflows requiring manual service calls
  • Poor discoverability for logging-related features

As ROS 2 logging is crucial for debugging and production diagnostics, users need a clear and ergonomic CLI to interact with it.

Proposed Functionality

The REP proposes introducing a new ros2 log CLI command group with the following subcommands:

Subcommand Description
ros2 log list List nodes that support runtime log configuration
ros2 log levels Show all valid log level values (DEBUG, INFO, WARN, ERROR, FATAL)
ros2 log get <node> Retrieve the current log level of a node
ros2 log set <node> <level> Set the log level of a node
ros2 log watch Tail/monitor logs from nodes via rosout
ros2 log describe <node> Display metadata (available loggers, effective levels)

Previous Discussions

This proposal builds on previous community discussions:

Looking forward to your feedback! :rocket:

This discussion thread follows REP-0001:2025 Step 4. Substantial discussion should happen in this public topic to ensure all interested people can participate.

15 Likes
ROS News for the Week of February 16th, 2026
ROS News for the Week of July 6th, 2026
ROS News for the Week of January 19th, 2026
2

Thanks for opening the REP. I think it will help developers to better utilize logging during development and analyzing of systems.

I just have the following remarks:

  • Would it be beneficial to have an environment variable to globally set enable_logger_service for all nodes, so that it’s easier to benefit from the new feature without editing all launch files?
  • For ros2 log watch it would be nice to have a --format arg which allows to customize the output or even an json option.
  • The only major feature which is still missing is to view/filter all log msgs from the current or previous run similar to what journalctl provides. (As I understand it, the watch command only shows msgs which are received after the command is executed.)
    Currently it is easy to miss a warning or error in the output on the console, especially if multiple nodes output to the same console. A nice way to filter for specific msgs would be a game changer. But maybe this feature should/could be a new REP after this one is completed :wink:
3

sorry for being late to get back to you.

an environment variable to globally set enable_logger_service for all nodes

i am not inclied to create another environment variable for this, because global switch would great bunch of service endpoints without user’s intention. for enabling logger service, currently user application is responsible to set it on explicitly via NodeOption.

ros2 log watch it would be nice to have a --format arg which allows to customize the output or even an json option.

i guess so. this is minor enhancement so we can add it after official release. even without this, i think user can pipe the coverting command such as yq to change the format into json.

major feature which is still missing is to view/filter all log msgs from the current or previous run similar to what journalctl provides.

ros2log is not exactly where journalctl is. the thing is that journalctl knows the implementation details, but ros2log does not know the logging implementation. ROS 2 provides the rcl_logging_interface to conceal the logging implementation, could be spdlog, syslog or noop. so it is hard to know where to find the log from ros2log. curerntly we place ros2log as live log monitor.