How to Fix Linux journalctl Log Files Taking Too Much Disk Space (How to Vacuum Safely)

The systemd journal is quietly consuming a large and growing amount of disk space under /var/log/journal, sometimes without an obvious size cap in place. Unlike traditional flat log files, the journal is a structured binary format with its own retention rules, and by default those rules can allow it to grow substantially before anything intervenes.

The Problem

Checking disk usage reveals the journal directory as a significant, unexpected consumer of space:

$ du -sh /var/log/journal
12G     /var/log/journal

$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   45G  2.1G  96%  /

Checking journalctl's own reported disk usage confirms the same picture from a different angle:

$ journalctl --disk-usage
Archived and active journals take up 12.0G in the file system.

Why It Happens

The systemd journal, by default on many distributions, has generous or loosely bounded retention settings — it can grow to consume up to a certain percentage of the filesystem it lives on (commonly 10% by default) unless explicitly configured otherwise. On a server with verbose logging (frequent service restarts, chatty application logs going through journald, debug-level logging left on longer than intended), this default can allow the journal to grow into a genuinely significant chunk of total disk space over time. Common contributing factors:

• No explicit SystemMaxUse configured in journald.conf, leaving the journal to grow up to its permissive percentage-of-filesystem default rather than a deliberately chosen absolute limit.
• Persistent journal storage enabled (/var/log/journal existing, versus the default volatile in-memory-only journal on many minimal installs) without a correspondingly considered size limit, especially after enabling persistent logging for a specific troubleshooting need and then forgetting to also set a cap.
• Verbose or debug-level logging left enabled long-term for a service, generating far more log volume than intended for ordinary production operation.
• Frequent service crash-restart cycles (as covered in systemd auto-restart loop issues) each generating their own chunk of crash-related log output, compounding over time if the underlying restart issue isn't addressed.

The Fix

To immediately reclaim space right now, vacuum the journal down to a specific size or age — this is the safe, purpose-built way to reduce journal size, rather than manually deleting files under /var/log/journal directly:

sudo journalctl --vacuum-size=1G

Vacuuming done, freed 11.0G of archived journals from /var/log/journal.

Alternatively, vacuum based on age rather than absolute size, keeping only recent logs:

sudo journalctl --vacuum-time=7d

Both approaches only remove archived (rotated) journal files, never the currently active journal file, so this is safe to run without risking loss of the most recent, currently-relevant log data.

To prevent the journal from growing unbounded again in the future, set an explicit, deliberate size cap in the journal's configuration rather than relying on the loosely bounded percentage-based default:

sudo nano /etc/systemd/journald.conf

[Journal]
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=2G
MaxRetentionSec=1month

SystemMaxUse sets a hard cap on total journal size, SystemKeepFree ensures the journal always leaves a minimum amount of free disk space regardless of its own cap, and MaxRetentionSec caps how long entries are kept regardless of size, giving you both a size and a time-based bound working together.

Restart the journal service for the new configuration to take effect:

sudo systemctl restart systemd-journald

Verify the new limit is actually being respected going forward:

journalctl --disk-usage

If a specific service is generating disproportionately verbose logs and driving most of the growth, check its logging level and adjust it if it's been left more verbose than actually needed for ordinary production operation:

journalctl --disk-usage -u myapp

journalctl -u myapp --since "1 hour ago" | wc -l

An unusually high line count for a short time window points at a specific service worth investigating and tuning down independently of the broader journal size limit.

Still Not Working?

If space is still tight even after vacuuming and setting a cap, check whether the journal is configured to store logs on a separate, smaller partition than you expect, or whether other large consumers under /var/log (traditional flat log files outside the journal entirely, like Nginx or application-specific logs) are actually the bigger contributor rather than the journal itself:

du -sh /var/log/* | sort -rh | head -10

This sorts every subdirectory and file under /var/log by size, largest first, giving you a clear picture of whether the journal specifically is the actual problem or whether a different, traditional log file elsewhere is the real space consumer that also needs its own rotation and retention policy addressed separately from the systemd journal's own configuration.