Color format issue with newer tag and --disable-ui

[xaru8145]

Hi, Thanks so much for developing this package, it has been extremely useful! I have encountered an issue when using the option --disable-ui related to the color format. I am using ROS Melodic in Ubuntu 18.

When using tag 2.3.2 (up to 2.4.0) I see in the terminal the correct color code (red for ERROR, yellow for WARN and white for INFO):

However, when using the latest tag 2.5.1 (also happens in 2.5.0), all messages are white regardless of the log level:

Is this an expected behavior? When running both version without --disable-ui the color coding is fine. Thanks in advance!

[xqms]

Yes, this is expected behavior. Since #172 landed, we parse the output of ROS nodes to determine severity. When --disable-ui is used, we assume that the output goes to a log file and do not generate color escape codes.

Can you tell a bit more about your use case? What are you doing that you cannot use the UI but want colors?

[xaru8145]

Okay, thanks for the clarification!

We are in a project phase where we want the flexibility to launch our system on startup (we use an entrypoint of a docker compose) but at the same time have the option to launch manually.

When the system is launched upon startup, I have 2 ways of visualizing the console output in realtime: I can use docker compose logs or journald (through docker not rosmon) with the follow option. If the ui is enabled, all the screen is full of node names and I cannot see the actual messages. Therefore, I need to disable the ui. When the system is launched manually, the ui is more convenient. What I was looking for is to disable the ui in both cases but maintaining the colors which help debug potential problems. I guess I can try to identify who launches the system and then based on that enable or disable the ui.

I wanted to create log files for when I am not able to monitor the screen, in which case I do not care about the ui or the colors. Also, since I am using docker the option to log directly to journald gets tricky since it is the docker daemon that logs to journald and not the internal processes.

[xqms]

I didn't fully understand your setup, but one thing you might not be aware of: You can enable rosmon's journal integration (--log=syslog) and bind-mount /run/systemd/journal/socket in the container from the host. That will log everything into the systemd journal on the host, which has full color support and includes a lot of meta-information, such as the node that produced the output.

I guess we could enable color escape codes for --disable-ui if we detect that the output is going to a terminal. I don't really have the bandwidth to work on that now, though.

[xaru8145]

Thanks for the insight and the quick response! How do you retrieve the logs after? Using journalctl -u and the name flag used for rosmon?

I can also detect who launches the system and based on that set the --disable-ui accordingly, so no need to change any code.

[xqms]

Here's the information we send to journald: https://github.com/xqms/rosmon/blob/4b007454c1b490c551774d99918cabc5c9df4839/rosmon_core/src/logger.cpp#L134-L143

If I remember correctly that means you can filter using journalctl -u rosmon@my_launch_file.launch. Hmm, including the name passed into --name would be nice, though :thinking:

[xaru8145]

I had to use SYSLOG_IDENTIFIER as in journalctl SYSLOG_IDENTIFIER=rosmon@my_launch_file since using journalctl -u rosmon@my_launch_file did not work for me.

And yes, I agree that using the name when provided as a syslog_identifier would be nice!

[romainreignier]

Hi, I have the same issue that @xaru8145, I have lost the colors in --disable-ui mode since 2.5.0 but for a different use-case. In my ROS system, I have a dynamic part where a second launch file is launched with a QProcess in a ROS node launched by a first launch file. The first launch is launched by rosmon with a UI while the second is launched with disable-ui and I use QProcess::setProcessChannelMode(QProcess::ForwardedChannels) to forward stdout and stderr. I know that this use-case is not standard and might not be widespread, but I was using this setup with great success for the last 5 years and with the new version, I have lost the colors. I feel like adding a new argument like --disable-ui-with-colors or adding --with-colors to use with --disable-ui might be easier than trying to auto-detect if run in terminal because it might not always work for all the use-cases.