The journal is consuming your root partition
You run df -h and see /var/log/journal has grown to 15 gigabytes on a 50-gigabyte partition. Or you try to pull logs from three days ago and journalctl returns nothing because the rotation policy flushed them an hour ago. The default systemd journal settings work for most servers, but they ignore your specific storage constraints and retention needs. You need to tell journald exactly how much disk space to claim and how long to keep the data.
How systemd manages logs
systemd-journald collects logs from the kernel, services, and user sessions. It writes them to binary files in /var/log/journal. Without limits, it keeps writing until the disk fills up. With limits, it rotates files based on size, age, or sync intervals.
Think of the journal like a set of notebooks. SystemMaxUse is the shelf space you allow for all notebooks. MaxRetentionSec is how long you keep a notebook before shredding it. MaxFileSec is how often you start a fresh notebook. If you don't set these, journald uses conservative defaults that might save too much disk or discard logs too quickly for your workflow.
The journal is a binary database, not a text file. You cannot edit logs with a text editor. Use journalctl to read and journald to write. The binary format includes structured metadata and indexing, which makes searching fast even with gigabytes of data.
Configuration lives in /etc/systemd/journald.conf. The package ships a template in /usr/lib/systemd/journald.conf. Never edit the file in /usr/lib. Your edits in /etc override the package defaults. If you modify /usr/lib, the next package update will overwrite your work.
Restart the service. The config file is read on startup. Editing the file does nothing until the daemon reloads.
Configure size and rotation
Check the current limits before changing anything. This shows you the baseline and helps you calculate the delta.
sudo journalctl --disk-usage # Shows current usage and configured limits
Here is how to set size limits and retention policies in the configuration file. Adjust the values to match your disk capacity and compliance requirements.
[Journal]
# Limit total disk usage for persistent logs to 500 megabytes.
# Journald will delete oldest files first when this limit is reached.
SystemMaxUse=500M
# Keep logs for a maximum of 7 days regardless of disk usage.
# This prevents logs from accumulating indefinitely on a large disk.
MaxRetentionSec=7d
# Rotate the log file every 24 hours.
# Smaller files make it easier to pinpoint when an event occurred.
MaxFileSec=1d
# Compress logs to save space. Enabled by default, but explicit here.
Compress=yes
# Limit individual file size to 50 megabytes.
# Prevents single files from becoming too large to manage.
SystemMaxFileSize=50M
Restart the service to apply the new configuration. The daemon reads the file and enforces limits immediately.
sudo systemctl restart systemd-journald # Reloads config and enforces new limits immediately
After restarting, verify the service is active. Use systemctl status systemd-journald to check the state. If you see errors, run journalctl -xeu systemd-journald to see the explanatory text and jump to the end of the log. Most sysadmins type journalctl -xeu <unit> muscle-memory style when debugging service failures.
Check the disk usage immediately. If the number hasn't dropped, the rotation hasn't triggered yet. Wait for the next sync or force a vacuum.
Verify the configuration
Confirm the new limits are active and check disk usage. This proves the configuration took effect.
sudo journalctl --disk-usage # Displays current usage against the configured limits
sudo systemctl status systemd-journald # Confirms the service is running without errors
Run journalctl --disk-usage first. Read the actual numbers before guessing whether the rotation worked.
Common pitfalls and errors
The configuration file uses a simple key-value format. A typo in the unit suffix breaks the parser. If you type SystemMaxUse=500 without M, journald interprets the value as bytes, not megabytes. The service will likely start, but the limit will be effectively zero.
systemd-journald[1234]: Failed to parse byte size '500', ignoring: Invalid argument
If /var/log/journal does not exist, logs are stored in /run/log/journal and vanish on reboot. SystemMaxUse only applies to persistent storage. Create the directory and set permissions if you want logs to survive a reboot.
sudo mkdir -p /var/log/journal # Creates the directory for persistent logs
sudo systemd-tmpfiles --create --prefix /var/log/journal # Sets correct ownership and permissions
sudo systemctl restart systemd-journald # Moves logs to the new persistent location
RuntimeMaxUse controls the volatile journal in RAM. If you are debugging a boot issue and the system reboots, volatile logs are gone. Set RuntimeMaxUse if you need to catch transient errors before the next reboot.
SystemKeepFree ensures disk space for other things. If SystemKeepFree is set, journald stops writing when free space drops below that value, even if SystemMaxUse allows more. This protects the root partition from filling up. Use SystemKeepFree when you have a shared partition and must guarantee space for package installations or user data.
Vacuum the logs manually if you need immediate relief. The automatic rotation waits for the next sync cycle.
sudo journalctl --vacuum-size=200M # Reduces journal size to 200 megabytes immediately
sudo journalctl --vacuum-time=2d # Removes logs older than 2 days immediately
When to use specific limits
Use SystemMaxUse when you need to cap total disk consumption for persistent logs.
Use MaxRetentionSec when you must comply with data retention policies or prevent indefinite growth.
Use MaxFileSec when you want predictable file rotation intervals for backup or analysis tools.
Use RuntimeMaxUse when you are debugging boot sequences and need logs to survive a crash but not fill RAM.
Use ForwardToSyslog=no when you are running a dedicated syslog daemon and want to avoid duplicate log entries.
Keep defaults when you are running a standard desktop and the automatic management is sufficient.
Trust the package manager. Manual file edits drift, snapshots stay.