It seems that the log is consuming 205M. All of the files in the journal tree end with .journal

Am I missing something?

Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael FaradaySometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing----How to Ask Questions the Smart Way

Re: journalctl does not honor size limits

All of the files in 78170aeea466aef82a0611e20000059c are newer than the modification date of /etc/systemd/journalf.conf

I am at $DAYJOB right now. When I get home, maybe I'll wipe the journal folder out and allow it to start anew.

Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael FaradaySometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing----How to Ask Questions the Smart Way

Re: journalctl does not honor size limits

But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.-Lysander Spooner

Re: journalctl does not honor size limits

@Klitzool, the idea of setting *MaxUse and *MaxFileSize is that it is indpendent of the number of days before rotation. The old logrotate method is done by the number of days, but it seems to me that (if functioning correctly) doing it by size is superior. Say for example, you are on your machine all day and you have a service that is out of control and is constantly logging to the journal (though not quite fast enough to be simply ignored), then your logs will rotate much faster than if you had a perfectly smooth machine wich you only turned on for an hour a day.

Re: journalctl does not honor size limits

WonderWoofy wrote:

@Klitzool, the idea of setting *MaxUse and *MaxFileSize is that it is indpendent of the number of days before rotation. The old logrotate method is done by the number of days, but it seems to me that (if functioning correctly) doing it by size is superior. Say for example, you are on your machine all day and you have a service that is out of control and is constantly logging to the journal (though not quite fast enough to be simply ignored), then your logs will rotate much faster than if you had a perfectly smooth machine wich you only turned on for an hour a day.

Not at all. The logrotate tool coupled with cron is way more flexible than journal's internal mechanism. From man 8 logrotate.conf:

maxsize size
Log files are rotated when they grow bigger than size bytes even before the additionally speci‐
fied time interval (daily, weekly, monthly, or yearly). The related size option is similar
except that it is mutually exclusive with the time interval options, and it causes log files to
be rotated without regard for the last rotation time. When maxsize is used, both the size and
timestamp of a log file are considered.
minsize size
Log files are rotated when they grow bigger than size bytes, but not before the additionally
specified time interval (daily, weekly, monthly, or yearly). The related size option is similar
except that it is mutually exclusive with the time interval options, and it causes log files to
be rotated without regard for the last rotation time. When minsize is used, both the size and
timestamp of a log file are considered.

Re: journalctl does not honor size limits

Interesting, thanks for pointing that out Leonid.I. But still, it would seem that if you want this criteria to be honored, logrotate would still have to be run, and likely at a shorter interval than the standard cron.daily. See here:

logrotate(8) wrote:

It will not modify a log multiple times in one day unless the criterion for that log is based on the log's size and logrotate is being run multiple times each day, or unless the -f or --force option is used.

Re: journalctl does not honor size limits

What R the # of DAYS that the journal stores, when you R using this? I'm curious.

The oldest file is user-1000.journal dated 17 June. As for normal journal files (system@...journal), the oldest is dated 11 July. The conf file was last modified 17 April.

But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.-Lysander Spooner

Re: journalctl does not honor size limits

@Kilzool,The systemd journal does not have any functionality to rotate its logs out by the number of days. You can surely set the size limits as mentioned above. But in order to have a max of 5 days worth of journals, you'd probably have to have some other mechanism that clears out any journal files that more >5 days.

But this is pretty far off topic from ewaller's original thread topic. So try implementing something, do some testing, and if you have problems, start a new thread instead of hijacking an existing one.

Re: journalctl does not honor size limits

If single day takes at most 5 MB, 5 days won't exceed 25 MB ...Just 5 days worth of logs is a bit short, but

MaxFileSec=

The maximum time to store entries in a single journal file before rotating to the next one. Normally, time-based rotation should not be required as size-based rotation with options such as SystemMaxFileSize= should be sufficient to ensure that journal files do not grow without bounds. However, to ensure that not too much data is lost at once when old journal files are deleted, it might make sense to change this value from the default of one month. Set to 0 to turn off this feature. This setting takes time values which may be suffixed with the units "year", "month", "week", "day", "h" or "m" to override the default time unit of seconds.