On 2016-03-04 04:59, Andrei Borzenkov wrote:
04.03.2016 00:47, Carlos E. R. пишет:
On 2016-03-03 18:46, Andrei Borzenkov wrote:
No. Journald explicitly does not do filtering.
Does it allow purging entries from the database? Like doing a "logrotate".
There is MaxRetentionSec which is roughly analogous to logrotate time-based retention and *MaxUse and *MaxFiles that are roughly analogous to logrotate size-based retention.
Yes... right. But it is applied to all entries, not selectable by some filtering. For instance, remove early debug entries, leave critical messages for much longer. Likewise, depending on the facility.
Yes, I found that one, but seemed not to work.
That would be a bug.
Maybe... but I'm at 13.1.
Now I'm using:
[Journal] #CER #Storage=none SystemMaxUse=100M RuntimeMaxUse=50M MaxLevelStore=notice
which drastically reduced the content in the journal. Previously the size limit was not honoured, it started working half an hour ago.
All limits apply to archived journal files. It means if you have large files that being actively used they can well go over limit. I won't claim to understand in details how journald manages its storage.
Well, I don't have /var/log/journal. My current problem is, or was, with /run/log/journal, which grew to 300 MB in a week. Now, it is at 10MB/day. Notice that it is a problem because it is RAM. I will add a MaxRetentionSec clause now. Setting to "1w" Huh, now "systemctl status systemd-journald.service" hangs. systemctl restart systemd-journald.service also hangs. Finished. Took a minute. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)