Extensive logs on Debian 10 Supervised

Hi there!

Lately I’ve been looking around my Debian 10 installation (pure, on which I run Supervised - supported) and I can see that default system logger is rsyslogd.

When I go to /var/log I can see a lot of files with - together with archive - take up to 650MB:
I run installation with 21 add-ons, some of them are spamming the logs (like Wireguard) and I can’t even configure their verbosity.
What’s worse, some of those logs seem to go simultaneously to files like messages, syslog, daemon.log - making life of that SSD drive even worse. :wink:

So, regarding that, there are three questions:

  1. Do Supervisor need /var/log logs at all, or it’s journald solves it other way?
  2. Did anyone manage to encounter that and solve the problem of multiple log files with duplicated data?
  3. How to configure rsyslogd to make some of the addons more silent, while their name is hex’ed and changes every reboot (like on screen)?

I didn’t find any relevant thread on community, but in the end it would be nice to have it configured properly or even make up an recommendation.

To anyone reach this thread - I still have issues with that, further digging worth checking: Steps to reduce Write Cycles and extend SD/SSD life expectancy

@andriej Andriej, you found the community guide already, but perhaps we could discuss your specific questions here…

You can set a max file size and implement log rotation for your rsyslog files.
You can also check your current journalctl size, and restrict that if necessary.

journalctl --disk-usage			: check current disk usage
journalctl --vacuum-size=1GB	: clean up and reduce size to 1GB
journalctl --vacuum-time=1w		: remove all messages prior to the past week

Home Assistant makes use of the journald log driver, and to my understanding we can’t change this. But you can configure how the journald messages are parsed and written to the files in /var/log.

The Supervisor log level can be set from the command line using the HA CLI. So if you don’t care for all those debug and info messages, you can start by filtering them out by changing the Supervisor log level to e.g. “warning” or “error”.

# Change hassio_supervisor log level 
ha supervisor options -l warning

If you want to change the log level of homeassistant it can/must be done in configuration.yaml using the Logger configuration:

  default: critical
    # log level for HA core
    homeassistant.core: fatal

The messages in journald are by default split out to different log files based on the configuration in /etc/rsyslog.conf. Eliminating duplication can be done rather easily by changing this file (and then restarting rsyslog).

The duplication and how to change/prevent it is explained in the E. rsyslog section of the community guide. Because rsyslog by itself is OS-specific (operating system) and not directly related to Home Assistant, you can find many articles on internet how it can be configured, starting with the RSyslog official website.

First concern here is that unfortunately Home Assistant logs ALL messages as errors, even debug and info messages. This makes journald and rsyslog filtering on log level impossible.

To filter out specific messages you need a reliable handle that can be used to identify them uniquely, without filtering out wanted messages by mistake. You could add a new rsyslog filter by adding up a combination of filters that accurately identifies your unwanted messages:

# Ignore all messages containing <string a> and not containing <string b>.
if ($msg contains "string a") and not ($msg contains "string b") then { stop }

I assume you already tried to filter the logging for these addons using the HA Logger settings in configuration.yaml?

Thank you for the reply.

I’m fully satisified with what HA logs and I’ve setup logger properly. Whole post was more about the /var/log and Debian underlying, as lately with more and more complicated addons (AdGuard, DNS and whole setup) once my logs became 6GB and growing.
Size doesn’t matter as I have a lot of spare space… what I’m more worried about is SSD wear leveling behind that. Writing tons of gigabytes of repetitive information (such as DNS resolves of DNS supervisor component) is what worreid me more.
I’ll spend some time to go through that community docs tho.