Currently hassio_supervisor continuously generates debug and info messages. It is expected that setting the logger level to e.g. “error” or “critical” should filter out these undesired messages, as it is done for “core” and other components. But logger filtering does not work for hassio_supervisor.
As workaround one could try and filter these messages in downstream systems like journald or rsyslog, but this also does not work because these debug messages are output on STDERR, and are therefor flagged as errors.
Apart from putting unnecessary load on system resources and wearing out SD/SSD storage, It is also not possible to run a report like “give me all the errors that occurred on the system today”, because 99% of those errors are no errors at all.
Current situation:
Supervisor version: “supervisor-2021.03.6”
Logger setting in configuration.yaml:
logger:
default: critical
logs:
# log level for HA core
homeassistant.core: fatal
...
hassio_supervisor messages in journalctl:
Note:
“PRIORITY=3” is synonymous to “log level = ERROR”.
The debug nature of these messages, with statuses like “starting” and “running”. They have no meaning to the user. At the very least a “INFO” type of message should be something like “check x completed successfully”, and a real ERROR should be “check x failed with reason xyz”.
journalctl CONTAINER_NAME=hassio_supervisor PRIORITY=3 --since today
Mar 20 00:40:41 RPiHome 5774bf08478f[6803]: 21-03-20 00:40:41 INFO (MainThread) [supervisor.resolution.check] Starting system checks with state CoreState.RUNNING
Mar 20 00:40:41 RPiHome 5774bf08478f[6803]: 21-03-20 00:40:41 INFO (MainThread) [supervisor.resolution.checks.base] Run check for IssueType.FREE_SPACE/ContextType.SYSTEM
Mar 20 00:40:41 RPiHome 5774bf08478f[6803]: 21-03-20 00:40:41 INFO (MainThread) [supervisor.resolution.checks.base] Run check for IssueType.SECURITY/ContextType.CORE
Mar 20 00:40:41 RPiHome 5774bf08478f[6803]: 21-03-20 00:40:41 INFO (MainThread) [supervisor.resolution.checks.base] Run check for IssueType.PWNED/ContextType.ADDON
Mar 20 00:40:41 RPiHome 5774bf08478f[6803]: 21-03-20 00:40:41 INFO (MainThread) [supervisor.resolution.check] System checks complete
Mar 20 00:40:41 RPiHome 5774bf08478f[6803]: 21-03-20 00:40:41 INFO (MainThread) [supervisor.resolution.fixup] Starting system autofix at state CoreState.RUNNING
Mar 20 00:40:41 RPiHome 5774bf08478f[6803]: 21-03-20 00:40:41 INFO (MainThread) [supervisor.resolution.fixup] System autofix complete
...
@ludeeus, thanks for that. Changing the log level to “warning” works great for supervisor.
ha supervisor options -l warning
I still think that the logger setting in configuration.yaml should also apply to supervisor (and other HA components like hassio_audio), in the same way that it changes the logging level for core. This would standardize how the log level is configured for HA components and integrations alike. Currently supervisor must be configured from the command line, while core has no command-line log options and must be configured from yaml. And then there is audio, that does neither - no command-line options and not following the logger setting. But this is indeed another topic.
On the topic, I don’t see any difference when I do the following (before applying the filter mentioned above). I’d expect to see a lot less output when filtering on errors.
ha supervisor logs --log-level=INFO
ha supervisor logs --log-level=ERROR
It can’t. they are different runtimes (containers), the logger integration can only change python logging for elements that runs under the homeassistant python prosess.
run ha supervisor restart after chaning logging for the supervisor
The CLI logging change for supervisor took effect without the need to restart it. Thanks again for that, it was a thorn in my side for some time now.
From this I understand that there is no process-to-process communication possible/happening between homeassistant and supervisor? Else that would be the easy way out… let homeassistant read configuration.yaml and then “update” supervisor with relevant changes.
Well, technically configuration.yaml is a file on the OS that can be read by any process (with the necessary permissions). So supervisor could in theory get some of its configuration from there.
While technically possible, it should not be done, that would result in duplicate methods for the same thing, and will add too much overhead to development.
This would then also be the only thing that is configured that way for the supervisor, which adds confusion to the user/people trying to help.
Changing settings for the supervisor can/should only be done with CLI/Supervisor UI, changing logging is considered “advanced” not something everyone will/should do. so that will not be in the UI (CLI only)
In this case it is advanced because we make it difficult and therefore advanced. Logging, and changing its behavior, is in general not advanced and covered well in the HA documentation. Note that in this documentation it is mentioned (right at the top):
" The logger integration lets you define the level of logging activities in Home Assistant."
This is a generic statement, suggesting it applies to logging throughout HA. There is no mention that it only applies to certain components and that for others logger settings are not relevant. There are even HA components like core in the example, further strengthening the perception that this is also applicable to HA itself (the core, or kernel, so to speak) and not only integrations and add-ons. I’d argue that HA core is just as abstract to the general user as supervisor, and yet core is covered by the non-advanced Logger while supervisor is not. So maybe the advanced part specific to supervisor is indeed on the developer/implementation side of things and not so much the user.
But hey, you spent time to answer and helped me to reduce the logging on my system, and for that I’m grateful.
