On modern Linux distributions running systemd—including Ubuntu, Debian, Fedora, Arch Linux, and CentOS Stream—the systemd-journald daemon is responsible for capturing kernel logs, service output, and system events. Unlike classic text-based syslog files stored in /var/log/, systemd journal logs are indexed, binary files kept in /var/log/journal/. Over weeks and months of heavy server use, these logs can silently swell to dozens of gigabytes, consuming critical storage space.
Fortunately, systemd includes built-in maintenance utilities to inspect, rotate, and safely purge aged logs. In this guide, we explore how to measure journal footprint, vacuum old records using size and time constraints, and configure permanent retention thresholds.
Checking Current Journal Log Disk Usage
Before deleting any log entries, assess exactly how much storage the systemd journal is consuming across your root filesystem. Execute the following command in your terminal:
journalctl --disk-usage
The output displays the aggregate disk footprint and the active storage directory, typically formatted as:
Archived and active journals take up 4.2G in the file system.
Understanding the difference between active and archived journals is essential when managing journal capacity:
| Journal State | File Extension | Modification Status | Vacuum Eligibility |
|---|---|---|---|
| Active Journal | system.journal / user-*.journal |
Currently open; receiving live service output | Cannot be deleted until rotated |
| Archived Journal | system@*.journal |
Closed; sealed with cryptographic hashes | Directly purged by --vacuum commands |
Monitoring storage capacity regularly using tools like head and tail for log inspection or checking open processes with the ss command in Linux helps identify services generating excessive log noise.
Step 1: Rotating Active Journals
Before running a vacuum operation, you should rotate the active journal files. Rotating forces systemd-journald to seal the currently open log files and start brand-new journals. This ensures that historical logs generated up to this very moment become eligible for cleanup:
sudo journalctl --rotate
Step 2: Vacuuming Logs by Size or Time Retention
systemd provides two primary mechanisms to trim logs: size-based limits and time-based limits. Choose the approach that best fits your administrative policies.
Vacuuming by Total Disk Size
To reduce journal logs so that their total footprint does not exceed a defined threshold (for example, 500 Megabytes or 1 Gigabyte), use the --vacuum-size flag:
sudo journalctl --vacuum-size=500M
The terminal will indicate which archive files were removed and verify the updated total storage footprint:
Deleted archived journal /var/log/journal/26a.../[email protected] (128.0M).
...
Vacuuming done, freed 3.7G of archived journals from /var/log/journal/26a...
Vacuuming by Age
If compliance or troubleshooting requirements mandate retaining the last fortnight of system events, trim older records using the --vacuum-time flag:
sudo journalctl --vacuum-time=14d
You can specify durations in days (d), weeks (weeks), or months (months). Any archived journal files containing records older than the specified duration are pruned immediately.
Vacuuming by File Count
You can also constrain the quantity of discrete journal files retained on the disk:
sudo journalctl --vacuum-files=5
Step 3: Setting Permanent Size Limits in journald.conf
While manual vacuuming resolves urgent disk shortages, setting permanent limits prevents the journal from bloating again in the future. Edit the main configuration file:
sudo nano /etc/systemd/journald.conf
Locate the [Journal] section and uncomment or configure the following directives:
[Journal]
SystemMaxUse=1G
SystemKeepFree=2G
MaxRetentionSec=1month
Here is what these configuration parameters enforce:
SystemMaxUse=1G: Limits total disk usage of persistent journals to 1 Gigabyte.SystemKeepFree=2G: Ensures systemd-journald always leaves at least 2 Gigabytes of free disk space on the partition.MaxRetentionSec=1month: Automatically prunes entries older than 30 days.
Save the file (press Ctrl+O, then Enter in Nano) and exit (Ctrl+X). Then, restart the journal daemon to apply the new rules immediately:
sudo systemctl restart systemd-journald
For administrators seeking systematic text extraction, pairing journal output with the awk command for text processing facilitates rapid error reporting across historical log streams.
Frequently Asked Questions
Is it safe to delete files inside /var/log/journal/ using the rm command?
Directly deleting journal files with rm -rf /var/log/journal/* is strongly discouraged. Doing so can cause systemd-journald to lose file tracking handles and corrupt runtime metadata. Always use journalctl --vacuum-size or --vacuum-time to purge logs safely through the daemon API.
Why did the vacuum command not free as much disk space as expected?
Vacuuming only prunes archived journal files. If you did not run sudo journalctl --rotate before vacuuming, the currently active journal file cannot be pruned. Run the rotate command first, then repeat the vacuum instruction.
Where are volatile runtime logs stored if persistent logging is disabled?
If persistent logging is disabled, journal files are stored temporarily in /run/log/journal/ within RAM. These volatile logs are wiped automatically on system reboot and configured using RuntimeMaxUse in journald.conf.