Surprise, after 2 weeks my event.log and openhab.log are 5 MBytes, by chance OH2 is running on a 250 GBytes USB disk, o I still have some time before my disk is full.
With OH1 there is a way to reduce the log activity, daily, automatically archive the log files and to keep a defined number of versions.
Is this still possible with OH2?
OK, I understand that the log file policy is SizeBasedTriggeringPolicy and I can modify the size before the file will be renamed for rollover.
However I don’t see how these files will be compressed and where is the retention policy defined.
It’s probably important to note that by default the OH2 logging policy is 16 MB and it only keep the most recent ten rolled over files for a total of.
(1 log file + 10 rolled over) * 2 log files * 16 MB = 352 MB max space used by log files.
sihui linked to the docs that should tell you how to adjust this as needed, but unless you had an SD card that starts to fail and the log rollovers fail (which is how I discovered I had a failing SD card once) you will never fill up that 250 GB disk. So you don’t really have anything to worry about here. Only spend the time on this if you are curious to how it works or have a need or desire to change the settings for some other reason.
I had already a look to the Log4J which is double dutch for me (I would like to focus on my house automation environment).
Yes I had already experience with OH1 filling up my SD card and destroying my Raspberry environment). This is the reason I used openhabian on one USB disk, with purpose to add some multimedia apps.
So I have to stop OH logs, (if this is possible, I don’t see any console command to do that) or to reduce the size of the log files
It is a pity because compression and retention functionality was part of OH1.
First, you indicated you are running on an external USB disk so the SD card wear out issue shouldn’t be a concern for you.
Second, reducing the size of the log files using compression will not solve the SD card wear out problem, it will exacerbate it. What wears out the SD card is not how much is stored on it at any given time, it is how many bytes are written to the file. If you compress the log files, then you are performing two writes to the SD card. It is actually far better from an SD usage perspective to just leave it uncompressed on the card rather than compressing it.
It is useful to understand here what happens when a log file rolls over. The file is not copied to a new location on the SD card, which would be bad. Instead it is just renamed so all the contents of the file are not rewritten. If you compress it, when your main log file rolls over you’d have to rewrite it which which means more writes, not fewer writes.
If you are concerned about the logs writing to disk you really have three choices:
configure the logging so less get’s logged, reducing the number of writes
completely turn off the logging
move the logging to some other file system (e.g. a tempfs file system which only exists in memory)
You can turn off logging in the config file in $OH_USERDATA/etc folder.
sihui showed you the parameter that will reduce the size of the log files. If you drop that field to 5 then the logs will only take up 110 MB. But that isn’t going to reduce the number of writes. It’s not the size of the logs that get saved to disk, it’s the number of writes.
But since you are not running off of an SD card or USB thumb drive, this is a non-issue for you.
Retention and compression are a functionality of OH2 as well. But neither of them actually address the problem you are trying to solve, and in fact you don’t even have the problem you are trying to solve.
Thanks for the explanations, you are right, what was killing my SD card was not the size of the file, but the excessive writes. Reducing the file size was necessary because of my SD card scarce size capacity, the reason I have moved my OH1 to a WD Pi drive few years ago.
A good thing to know is that the file size or the amount or of files will not grow indefinitively.
Reducing the files size and the possibility to stop it once the configuration is stable may be an alternative.