2

I have a system running CentOS 7, with more than 1T free disk space. The systemd version is 219. I have configured journald with the following settings:

Storage=persistent
SplitMode=none
SystemMaxUse=50G
SystemMaxFileSize=1G
#MaxFileSec=1month (default)

However, the resulting journal files are smaller than 1G, they are cut at about 500M, as can be seen in this screen shot.

enter image description here

I'm doing intense testing of the system, the log is filled with more than 1G per day, so it is not the MaxFileSec that is kicking in. I noted that the group id differs for the files, maybe that is a clue. However, as seen by the time stamps in the screenshot, the two log files on top does not seem to be filled anymore.

My question is, why are the size of the journal files not reaching the configured 1G?

Edit: Corrected parameter names as pointed out by Mark below, it was correct on the system though.

Mark Stosberg
  • 3,901
  • 24
  • 28
joaerl
  • 397
  • 1
  • 3
  • 11
  • Thanks to the suggestions by Mark in the answer below I found out that the files were rotated because the "data has table" reached a certain threshold, rather than the file size hitting SystemMaxFileSize. As pointed out by Mark, the docs only promises that the files should not exceed SystemMaxFileSize, but in this case another limit is reached first. From reading the source code (link in Marks answer) I found that the size limit for that data hash table is proportional to SystemMaxFilesSize though. – joaerl Jan 26 '17 at 13:53
  • I also found that there is no limit on maximum number of files in rotation (in the version I am using, in newer versions there is a setting for this), so I don't see there should be any risk of log entries being thrown away before reaching SystemMaxUse (or becoming too old, if you have that parameter set) – joaerl Jan 26 '17 at 13:55

1 Answers1

4

Nothing in the docs in man journald.conf promises to make the log files as large as SystemMaxFileSize=. The docs only promise not to exceed that limit.

From an amateur reading of the C source code, my interpretation is that there is a "minimum file size", but that is only 512k, so that shouldn't be in play here. There is also "FILE_SIZE_INCREASE", which is related to allocating incremental file growth. My reading is to expect the file size to grow within 8 MB of the SystemMaxFileSize before rotation happens.

If you search the whole systemd source tree for SystemMaxFileSize, you'll find it gets translated into the "max_size" variable in the ".c" file linked above.

Since the docs didn't fully answer the question, reading the related source code may give you the fuller insight into the behavior that you were looking for.

Mark Stosberg
  • 3,901
  • 24
  • 28
  • thank you. Unfortunately it was a typo in the question only, and not on the system. Have edited the question. – joaerl Jan 23 '17 at 14:25
  • I guess that makes sense, but it also makes me a bit uncomfortable. Because using the same reasoning the total size might not be capped at SystemMaxUse, but a lower value. That could mean that log entries are deleted even though there is still room for them. Of course I will test this too, but not understanding how journald makes these decicions makes me wonder if the test results will hold true from time to time. It would make more sense to me if log files would not be split until reaching the max size, then I would not worry about these things. – joaerl Jan 24 '17 at 11:35
  • 1
    I review the source code and extended my answer some. – Mark Stosberg Jan 24 '17 at 15:47