journald Vacuum: How to Shrink Disk Usage

journald vacuum means deleting archived journal files with journalctl --vacuum-size=, --vacuum-time=, and --vacuum-files= so disk use drops now. For steady-state limits, set Storage= and SystemMaxUse= (or Runtime*) in journald.conf.

This post covers disk usage and retention only. Finding logs with filters (-u, -p, -S, …) is a separate angle (#17). No pricing.

What do the vacuum options do?

One-line answer: --vacuum-size= caps space, --vacuum-time= caps age, --vacuum-files= caps file count—and you may combine them. Pair with --rotate when you need active files archived before the vacuum.

Check usage first:

journalctl --disk-usage

Immediate cleanup examples:

sudo journalctl --vacuum-size=200M
sudo journalctl --vacuum-time=2weeks
sudo journalctl --vacuum-files=5
sudo journalctl --vacuum-size=500M --vacuum-time=30days --vacuum-files=10

Per journalctl(1):

  • Vacuum operates on archived journals only—not the currently active files.
  • --disk-usage can stay high after a vacuum because it still includes active files.
  • Combining --rotate archives active files first, so vacuum can reclaim as much as possible of what has been written so far:
sudo journalctl --rotate --vacuum-size=200M

Setting a vacuum parameter to 0 means “do not enforce that limit” (redundant). Size suffixes are K/M/G/T (base 1024); time uses systemd.time units (s, m, h, days, weeks, …).

Persistent vs volatile?

One-line answer: Storage=persistent keeps data under /var/log/journal across reboots; volatile keeps it under /run/log/journal and loses it on reboot; auto behaves like persistent when /var/log/journal exists.

Configure in /etc/systemd/journald.conf or drop-ins under /etc/systemd/journald.conf.d/.

StoragePathAfter reboot
persistentPrefer /var/log/journalKept
volatile/run/log/journalGone
autoDepends on directory existenceConditional
noneMinimal journal storage—

Size knobs split by prefix:

  • System* (SystemMaxUse=, SystemKeepFree=, …) — persistent /var/log/journal
  • Runtime* — volatile /run/log/journal

Example persistent cap:

# /etc/systemd/journald.conf.d/size.conf
[Journal]
Storage=persistent
SystemMaxUse=200M
sudo mkdir -p /etc/systemd/journald.conf.d
sudo systemctl restart systemd-journald

journald.conf(5) notes that if limits are already violated at start, the effective limit may rise to match free space, and journald will not later delete existing files just because something else filled the disk. Practical combo: vacuum when urgent, SystemMaxUse= for the ceiling.

Early boot may write volatile until journalctl --flush (or systemd-journal-flush.service) moves data into /var/log/journal when persistent storage is available.

Do service logs survive?

One-line answer: Vacuum deletes by old archive files, not by unit filter. Keeping one service “forever” needs a path outside journal vacuum—file logs, remote collection, or a backup policy.

Easy mix-ups:

  1. Querying with journalctl -u nginx.service is not the same as reclaiming disk with vacuum.
  2. After vacuum, remaining active/recent archives are still filterable; deleted history is gone for every -u.
  3. Compliance retention for a subset of units belongs outside the journal (rsyslog/file redirect, remote syslog, backups).

Ops checklist:

  • Alert on disk → --disk-usage → --rotate --vacuum-size=…
  • Prevent regrowth → SystemMaxUse= / RuntimeMaxUse=
  • Long keep for one service → not vacuum; separate retention
  • Debugging with filters → use the filter howto, not this article

Wrap-up

To shrink journald disk use, vacuum archived files with --vacuum-*, then pin growth with Storage= and SystemMaxUse=. If reclaim looks weak, add --rotate because active files are not vacuum targets. Keep finding logs (filters) separate from freeing disk (vacuum).

Sources