2

I was perplexed to find that, when running for instance journalctl -f showed my logs to stop on Apr 20th, 8 months ago. I piped to less, journalctl | less and pressed G to go to the end, same thing.

Then I did journalctl | less and went down 'slowly' (ctrl+d), this way I was able to go way further than Apr 20th...

Theres a LOT in the logs! I think it is because there's a limit on what is being loaded. However, shouldn't the logs get rotated? Or somehow pruned without user intervention?

In my journald.conf SystemMaxFileSize/SystemMaxUse isn't set (a solution I found here). I could try the above, but I kinda want to get to the bottom of it.

I'm on Manjaro 5.8.18-1.

Any help or insights are greatly appreciated. Thanks!

Improve this question

3 Answers 3

Reset to default
6

The accepted answer is wrong.

  1. journald does, by default, limit its size, usually to 4GB. From the documentation:

SystemMaxUse= and RuntimeMaxUse= [...] SystemKeepFree= and RuntimeKeepFree= [...] The first pair defaults to 10% and the second to 15% of the size of the respective file system, but each value is capped to 4G.

  1. journald does in fact rotate its logs. From the documentation:

SystemMaxFileSize= and RuntimeMaxFileSize= control how large individual journal files may grow at most. This influences the granularity in which disk space is made available through rotation, i.e. deletion of historic data. Defaults to one eighth of the values configured with SystemMaxUse= and RuntimeMaxUse=, so that usually seven rotated journal files are kept as history.

If all you need is a peace of mind that your logs are rotated, they already are, you don't have to do anything.

If you want to manually decrease or increase log size limit, use SystemMaxUse=.

If you want to manually decrease or increase the pace at which they are rotated, use SystemMaxFileSize=.

Improve this answer
1
  • The systemd suite has been under rapid development in recent years: note that the original question was posted in December 2020. Perhaps the then-current version of Manjaro had some bug or an error in its default configuration that prevented journald log rotation? I've also encountered systems that ostensibly had journald log rotation configured, but had in actual fact failed to rotate their journals. Fortunately, as time progresses, those bugs seem to have eventually been squashed, regardless of their origin. Commented Jul 18, 2023 at 23:15
4

SystemMaxFileSize= and RuntimeMaxFileSize= control how large individual journal files may grow at most. This influences the granularity in which disk space is made available through rotation, i.e. deletion of historic data. Defaults to one eighth of the values configured with SystemMaxUse= and RuntimeMaxUse=, so that usually seven rotated journal files are kept as history. If the journal compact mode is enabled (enabled by default), the maximum file size is capped to 4G.

That means in theory your journald logs may occupy as much as 28GB per user.

To reduce the size of your logs, run sudo journalctl --vacuum-size=100M

To avoid the issue, please define SystemMaxUse - I personally have:

cat /etc/systemd/journald.conf.d/systemMaxUse.conf
[Journal]
SystemMaxUse=64M

More than enough for a home PC.

Improve this answer
0

If your issue is just that the log is too big to navigate using less, it might help to get the last lines to a file, then navigate that. For example, to look at the last 20 lines:

$ journalctl | tail -20 > temp.txt
$ less temp.txt

Instead of tail -20, you could grep for a certain date or time.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.