journald can keep logs only in memory, in which case a reboot, crash or attacker driven restart wipes them. With the default Storage=auto, logs persist only if the directory /var/log/journal exists. Create it, or set Storage=persistent, then set size limits so the logs cannot fill the disk.
Why this matters for security
When you investigate an incident, the logs from before the last reboot are often the ones you need. If they were in memory, they are gone. Persistent logging is a cheap baseline, and it is a prerequisite for anything more advanced like forwarding or review.
Check your current state
Run journalctl --list-boots. If it shows only one boot, you are probably on volatile storage. Also look for the directory:
ls -ld /var/log/journal
The journald.conf manual explains the rule. Storage= takes volatile, persistent, auto or none. With auto, journald behaves like persistent if /var/log/journal exists and like volatile otherwise, and auto is the default in the default namespace. Volatile data lives under /run/log/journal, in memory. The none setting drops everything it receives, though forwarding to the console or a syslog socket still works.
Turn on persistence
Either create the directory and restart the service, or set it explicitly in a drop-in file such as /etc/systemd/journald.conf.d/persist.conf:
[Journal]
Storage=persistent
SystemMaxUse=1G
Then systemctl restart systemd-journald. The manual adds a useful detail: journald starts with volatile storage at boot, and journalctl --flush, which the flush service runs on boot, moves it to persistent storage. If you switch back to volatile later, existing persistent data is not removed.
Set limits so logs do not eat the disk
SystemMaxUse= caps the disk space journald may use. SystemKeepFree= says how much to leave free. journald respects both and uses the smaller value. By default the first is 10 percent and the second 15 percent of the file system, each capped at 4G. The manual warns that only archived files are deleted when space is reclaimed, so actual use can exceed the limit for a while.
Pick limits on purpose. Too small and you lose history during an incident, too large and a noisy service can crowd out other data. If a service floods the journal, rate limits via RateLimitIntervalSec= and RateLimitBurst= drop messages after a burst, and that can hide events, so watch for suppression notices. See also log pipeline flooding.
Local logs are not enough
An attacker with root can alter or delete local files. The manual describes Forward Secure Sealing, enabled with Seal= when a sealing key exists, as a way to detect unnoticed alteration of persistent journal files. It detects, it does not prevent. Forward logs to another system as well, and read how to protect logs from tampering.
Safeguard offers compliance and evidence automation, which can help you show that log retention controls exist, and a free scan is at gold.safeguard.sh/scan.
Quick check
How do I know whether journald is persistent?
Check whether /var/log/journal exists and whether journalctl --list-boots shows more than the current boot.
Does Seal= stop an attacker from deleting logs?
No. Forward Secure Sealing helps detect unnoticed alteration. Forward logs off the host to keep a separate copy.
Sources
Last reviewed: 19 October 2026.
