257

I don't understand why the /var/log/journal/ folder is so big.

For example, by executing the command systemctl -f, i see the fill. If I click on an email on Thunderbird, it generates dozens of lines that I consider useless.

Currently, I have more than 1.5GB (du -h /var/log/journal/) generated in 1 day!

Is there a method to reduce this log considerably without stopping logging?

Improve this question
2
  • 1
    For me it's 2.5G on one 18.04 machine and 4.0G on another. What's the issue with the size?
    – 0xC0000022L
    May 11, 2020 at 12:13
  • 4
    "I don't understand why the /var/log/journal/ folder is so big." because it logs everything.
    – Rinzwind
    May 11, 2020 at 12:32

4 Answers 4

Reset to default
270

You can diminish the size of the journal by means of these commands:

sudo journalctl --vacuum-size=100M

This will retain the most recent 100M of data.

sudo journalctl --vacuum-time=10d

will delete everything but the last 10 days.

From man journalctl:

--vacuum-size=, --vacuum-time=, --vacuum-files=
    Removes the oldest archived journal files until the disk space they use
    falls below the specified size (specified with the usual "K", "M", "G" and
    "T" suffixes), or all archived journal files contain no data older than
    the specified timespan (specified with the usual "s", "m", "h", "days",
    "months", "weeks" and "years" suffixes), or no more than the specified
    number of separate journal files remain. Note that running --vacuum-size=
    has only an indirect effect on the output shown by --disk-usage, as the
    latter includes active journal files, while the vacuuming operation only
    operates on archived journal files. Similarly, --vacuum-files= might not
    actually reduce the number of journal files to below the specified number,
    as it will not remove active journal files.

    --vacuum-size=, --vacuum-time= and --vacuum-files= may be combined in a
    single invocation to enforce any combination of a size, a time and a
    number of files limit on the archived journal files. Specifying any of
    these three parameters as zero is equivalent to not enforcing the specific
    limit, and is thus redundant.

    These three switches may also be combined with --rotate into one command.
    If so, all active files are rotated first, and the requested vacuuming
    operation is executed right after. The rotation has the effect that all
    currently active files are archived (and potentially new, empty journal
    files opened as replacement), and hence the vacuuming operation has the
    greatest effect as it can take all log data written so far into account.
Improve this answer
5
  • 6
    Might be sufficient for most but if I got 10 dollars for every time some co-worker asks me what happen on a specific date where that date was more than 10 days (heck 1 here dared to ask about something happend 6 years ago :D ) I'd be rich. Log rotate (last sentence) might be a better method for most and it might be nice to focus more on that part :)
    – Rinzwind
    May 11, 2020 at 12:35
  • 1
    Vacuuming done, freed 3.7G of archived journals from /var/log/journal !
    – Tomachi
    Sep 10, 2020 at 3:05
  • 30
    Perhaps this can be edited to show how to set journald growth limits. Teach people to vacuum and they mitigate the problem once. Teach them to edit /etc/systemd/journald.conf and you teach them how to solve the problem permanently. Also, while not asked, a little bit about why journald is even necessary vs. text syslogs. Rinzwind's comment might otherwise prevent people from controlling journald when they actually have most everything journald offers in another source.
    – Kurt Fitzner
    Sep 16, 2020 at 12:11
  • 2
    After spending the afternoon carefully looking at documentation before proceeding with it, I run journalctl --vacum-size=100M thinking it would delete 100M of files in /var/log/journal ... I then see "Vacuuming done, freed 2.0G of archived journals", I'm an idiot! Oh well, not that I needed log files from March 2020 (I hope)
    – user199710
    Jan 30, 2021 at 18:33
  • 3
    One last thing -- in a professional environment, you should be running a centralized logging system with sufficient space to store a year's worth of logs (possibly compressed) for every system in the company (or at least six months worth) so that if your network is compromised, the compromise can be tracked back in time. So journald keeping more than a few days of local logs is literally a waste of local disk space in a professional enviornment.
    – eric.green
    Jul 19, 2021 at 19:21
194

As @kurt-fitzner wrote:

Teach them to edit /etc/systemd/journald.conf and you teach them how to solve the problem permanently.

More specifically: Activate the SystemMaxUse= option there, e.g. as SystemMaxUse=100M to only use 100 MB.

After editing, use service systemd-journald restart to activate the changed configuration. This will remove the excess logs.

journald.conf also has other options that might be useful.

Improve this answer
2
  • 9
    MaxRetentionSec is the parameter in /etc/systemd/journald.conf that controls how long to keep journal files. 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.
    – jeffmjack
    Feb 27, 2021 at 4:10
  • 14
    After editing, sudo service systemd-journald restart takes the changes into account and vacuums.
    – slv
    May 18, 2021 at 12:55
17

You also need to set this in /etc/systemd/journald.conf:

SystemMaxFileSize=100M

See: https://got-tty.org/journalctl-via-journald-conf-die-loggroesse-definieren (in German)

Improve this answer
0
5

Reading this was confused about SystemMaxFileSize vs SystemMaxUse options for journald.conf. This clears it up:

SystemMaxUse= and RuntimeMaxUse= control how much disk space the journal may use up at most. SystemKeepFree= and RuntimeKeepFree= control how much disk space systemd-journald shall leave free for other uses. systemd-journald will respect both limits and use the smaller of the two values.

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. If the file system is nearly full and either SystemKeepFree= or RuntimeKeepFree= are violated when systemd-journald is started, the limit will be raised to the percentage that is actually free. This means that if there was enough free space before and journal files were created, and subsequently something else causes the file system to fill up, journald will stop using more space, but it will not be removing existing files to reduce the footprint again, either. Also note that only archived files are deleted to reduce the space occupied by journal files. This means that, in effect, there might still be more space used than SystemMaxUse= or RuntimeMaxUse= limit after a vacuuming operation is complete.

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.

Improve this answer
1
  • What is the difference between SystemMaxUse and RuntimeMaxUse? The first controls the permanent logs in /var/log/journal (if the directory exists), the second controls /run/log/journal (in memory file system).
    – Hontvári Levente
    Jan 3 at 14:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.