Control journald Storage and Retention with a Safe Drop-in

You will configure systemd-journald with a small local drop-in, cap persistent journal storage at a known size, apply the change, and check the effective configuration. The examples use systemd 255.4-1ubuntu8.17, installed here on Ubuntu, and follow the configuration documented by the local [email protected](5) manpage.

Allow about fifteen minutes. You need an account with sudo access, a shell, and a working systemd journal. The commands that read configuration or inspect the journal are ordinary commands. Creating the drop-in and restarting journald require elevated privileges. Restarting the logger is a service operation, so use a maintenance window on a busy production host.

1. Inspect the installed version and current configuration

Confirm which systemd release and configuration files are in use before choosing an example. This is read-only:

$ dpkg-query -W -f='${Package} ${Version}\n' systemd
systemd 255.4-1ubuntu8.17
$ systemd-analyze cat-config systemd/journald.conf

The second command prints the main file followed by drop-ins from the vendor and administrator directories. On this machine it shows an administrator drop-in setting SystemMaxUse=1G, as well as a vendor drop-in enabling forwarding to syslog. Your output will differ. The useful question is whether an existing file already sets the option you intend to change.

Drop-ins in /etc/systemd/journald.conf.d/ override the main configuration and are sorted lexicographically with drop-ins from the other configuration directories. For a single-value option, the last matching assignment wins. A two-digit prefix makes that ordering visible, so this guide uses 60-local-limits.conf.

2. Create a local storage limit

Choose a limit that fits the host rather than copying the example blindly. The manpage says SystemMaxUse= limits persistent journal data under /var/log/journal; SystemKeepFree= also applies, and journald honours the smaller effective limit. Size suffixes such as M and G use powers of 1024.

First inspect the available space. This does not change anything:

$ df -h /var /run
Filesystem      Size  Used Avail Use% Mounted on
/dev/XXX         80G   32G   44G  43% /

The device name and figures are host-specific. If persistent storage is not enabled, a system limit will not control the active runtime journal. The runtime equivalents are RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize= and RuntimeMaxFiles=.

Now create the drop-in as root. Replace 1G with the limit you have selected:

$ sudo install -d -m 0755 /etc/systemd/journald.conf.d
$ sudo tee /etc/systemd/journald.conf.d/60-local-limits.conf >/dev/null <<'EOF'
[Journal]
SystemMaxUse=1G
SystemKeepFree=4G
EOF

The quoted heredoc delimiter keeps the file literal. The two settings work together: journald will not use more than 1 GiB for persistent journals and will try to leave 4 GiB free on the filesystem. If 4 GiB is more than the host can sensibly reserve, choose a smaller value. Do not set both values without considering the size of the filesystem and the host's other data.

$ sudo sed -n '1,40p' /etc/systemd/journald.conf.d/60-local-limits.conf
[Journal]
SystemMaxUse=1G
SystemKeepFree=4G

3. Check precedence and syntax

Ask systemd to assemble the effective configuration again. This is the most useful check for a drop-in because it shows whether another file sorts after yours:

$ systemd-analyze cat-config systemd/journald.conf | tail -35
...
# /etc/systemd/journald.conf.d/60-local-limits.conf
[Journal]
SystemMaxUse=1G
SystemKeepFree=4G

Look for the file path and values, not an exact number of lines. If another later-sorting file assigns either option, rename your file with a suitable higher prefix only after understanding why that file exists. A later vendor or administrator drop-in can otherwise win.

Check the file with systemd's verifier:

$ systemd-analyze verify /etc/systemd/journald.conf.d/60-local-limits.conf

No output and exit status 0 is the expected result. This verifies the unit and configuration syntax that systemd can parse; it does not prove that the selected limit is appropriate for your disk or that old journal files have already been removed.

4. Apply the setting without deleting journal data

Restarting journald makes it reread its configuration. It is a privileged, service-disrupting action:

$ sudo systemctl restart systemd-journald
$ systemctl is-active systemd-journald
active

Journald is socket-activated and its restart is normally brief, but applications can be affected if the host is logging heavily. Check the service status immediately. If it is not active, stop and investigate before making more changes:

$ systemctl --no-pager --full status systemd-journald

A new maximum does not necessarily shrink the journal at once. The manpage explains that size enforcement happens as files are extended and that only archived files can be removed. Existing persistent data is not deleted merely because you changed a limit. If you need immediate cleanup, use an explicit, reviewed journalctl --vacuum-size= or --vacuum-time= operation, but that is a separate data-removal decision and is outside this change.

5. Verify the journal and the storage mode

Confirm that the daemon is still receiving messages and that the journal can be queried:

$ journalctl -b -n 5 --no-pager
Sep 24 10:12:01 host systemd-journald[PID]: Journal started
...
$ journalctl --disk-usage
Archived and active journals take up 128.0M in the file system.

The timestamp, process ID, host name and disk usage are examples of variable output. A successful query and an active service are the important checks. The disk usage can remain above the new target until archived files are eligible for removal.

Remember the confusing default: in the default journal namespace, Storage=auto behaves persistently only when /var/log/journal exists, and otherwise behaves as volatile storage. Journald initially uses volatile storage during boot and is flushed to persistent storage by systemd-journal-flush.service when the conditions are met. Check the directory rather than guessing:

$ test -d /var/log/journal && echo 'persistent directory exists' || echo 'no persistent directory'
persistent directory exists

For a deliberate persistent policy, add Storage=persistent to the same drop-in, then restart journald and verify again. This can create or use /var/log/journal and has storage implications, so do not add it just to make SystemMaxUse= look active.

6. Understand limits, rate limiting and namespaces

SystemMaxUse is a capacity limit, not a retention promise. MaxRetentionSec= controls the maximum age of entries and defaults to 0, which disables time-based retention. SystemMaxFileSize= controls individual persistent journal files, while SystemMaxFiles= controls how many archived files are kept. Active files are not immediately deleted just to satisfy the file-count limit.

Do not confuse disk limits with message rate limiting. RateLimitIntervalSec= and RateLimitBurst= apply per service, with defaults of 30 seconds and 10000 messages before further messages from that service are dropped for the interval. A service can override those values with LogRateLimitIntervalSec= and LogRateLimitBurst= in its unit configuration.

Namespaced journals use /etc/systemd/[email protected] and matching drop-in directories. A setting in the default journald.conf.d directory is not a substitute for checking the namespace-specific configuration. In particular, the manpage gives different Storage= defaults for the default namespace and other namespaces. Identify the namespace and its own configuration before assuming the limits above apply to it.

7. Undo the change cleanly

If the new limit is wrong or you need to return to the previous configuration, move the drop-in out of the configuration directory and restart journald. Moving it preserves a copy for review:

$ sudo mv /etc/systemd/journald.conf.d/60-local-limits.conf /etc/systemd/journald.conf.d/60-local-limits.conf.disabled
$ sudo systemctl restart systemd-journald
$ systemctl is-active systemd-journald
active

The .disabled suffix is ignored by journald's drop-in lookup, which reads files ending in .conf. Confirm the effective configuration no longer contains the file:

$ systemd-analyze cat-config systemd/journald.conf | grep -F '60-local-limits' || echo 'drop-in is disabled'

Undoing the configuration does not restore journal files that a previous policy might have removed. Conversely, changing Storage= to volatile does not remove existing persistent data. Treat journal deletion as a separate, explicit operation with a retention decision behind it.