/flags/systemd/journalctl-vacuum-size
journalctl --vacuum-size and --vacuum-time: free disk space used by the journal
- tool
- systemd
- command
- journalctl
- flag
- --vacuum-size=, --vacuum-time=, --vacuum-files=
- default
- unset: no vacuuming; journald applies the journald.conf limits
- since
- systemd 218
journalctl --vacuum-size=SIZE deletes the oldest archived journal files until the archived files use less than SIZE. --vacuum-time=SPAN deletes archived files older than a time span, and --vacuum-files=N keeps at most N archived files. They are the supported way to free disk space when /var/log/journal has grown to gigabytes. Run them as root, and check the result with journalctl --disk-usage.
Syntax
journalctl --disk-usage # current total, active and archived
sudo journalctl --vacuum-size=500M # archived files below 500 MiB
sudo journalctl --vacuum-time=2weeks # drop archived files older than 2 weeks
sudo journalctl --vacuum-files=5 # keep at most 5 archived files
sudo journalctl --rotate --vacuum-time=7d # archive active files first, then vacuum
sudo journalctl --vacuum-size=1G --vacuum-time=1month # both limits in one runThe three options exist since systemd 218.
Values
| Option | Accepts | Removes |
|---|---|---|
| --vacuum-size= | K, M, G, T suffixes (base 1024): 500M, 2G | Oldest archived files until their total is below the size |
| --vacuum-time= | s (default), m, h, days, weeks, months, years: 7d, 2weeks | Archived files older than the span |
| --vacuum-files= | A number of files | Archived files beyond that count |
| 0 for any of them | - | Not enforcing that limit (redundant) |
Why the space does not always come back
The manual is explicit: vacuuming works only on archived files. --disk-usage reports active plus archived files, so after --vacuum-size=100M it can still show much more than 100M. Likewise --vacuum-files= may leave more files than requested, because active files are never removed. Combine with --rotate: all active files are archived first and new empty files are opened, so the vacuum can take everything written so far into account.
Granularity is per file. A single archived file larger than the remaining budget is either kept or deleted whole, so the result is approximate.
Make it permanent in journald.conf
Vacuuming is a one-off. To cap the journal continuously, set limits in /etc/systemd/journald.conf (or a drop-in in /etc/systemd/journald.conf.d/):
[Journal]
SystemMaxUse=500M| Setting | Meaning |
|---|---|
| SystemMaxUse= | Maximum disk space for persistent journal files in /var/log/journal |
| SystemKeepFree= | Disk space journald leaves free for other uses; the smaller limit wins |
| RuntimeMaxUse= / RuntimeKeepFree= | The same for volatile files in /run/log/journal |
| Defaults | MaxUse 10% and KeepFree 15% of the file system, each capped at 4G |
Restart systemd-journald after changing it.
Pitfalls
- Without root, vacuuming cannot remove the system journal files; run it with
sudo. - A unit that logs in a tight loop (for example one that keeps crashing and restarting, see Restart=on-failure) refills the space; fix the cause, then vacuum.
SystemMaxUse=and the other limits apply only to files journald manages; logs that a service writes to its own files under/var/logare not covered by the journal options at all.
FAQ
Why is --disk-usage still high after --vacuum-size?
Vacuuming removes only archived journal files. --disk-usage also counts the active files journald is writing to. Run journalctl --rotate --vacuum-size=500M to archive the active files first, then vacuum.
Is it safe to delete files in /var/log/journal by hand?
Use the vacuum options instead. They remove whole archived files in order from oldest, while journald keeps writing its active files; deleting the active ones by hand loses current logs.
How do I keep the journal small permanently?
Set SystemMaxUse= (and optionally MaxRetentionSec=) in /etc/systemd/journald.conf or a drop-in, then restart systemd-journald. Vacuuming is a one-time cleanup; the configuration is enforced continuously.