The systemd journal is the default log sink on most modern Linux distributions. Whether it retains anything after a reboot, and how much it retains, is decided by a small number of configuration directives that are rarely reviewed as a security control.
What journald is and where it writes
journald receives log messages over a socket, stores them in a binary format, and can optionally forward them onward. Its configuration lives in /etc/systemd/journald.conf and in drop-in files under the same directory.
The Storage= directive is the important one. auto means the journal is kept on disk if the directory exists, and volatile otherwise. volatile keeps everything in memory. persistent forces disk storage. none discards the journal entirely.
The default on most distributions is auto, which means persistence depends on whether /var/log/journal exists at boot. That directory may or may not be created, and an image that creates it once will keep it.
Why this is a security decision
Journal persistence decides how much of an investigation is possible. A hostile process that runs before shutdown, or an unexpected reboot during an intrusion, erases a volatile journal. The events that mattered most are the ones immediately before the loss.
Capping (SystemMaxUse= and the runtime equivalents) decides how far back retention reaches. A cap sized for ordinary operations may cover hours on a noisy host, and a single busy service can evict the evidence for everything else.
Forwarding (ForwardToSyslog= and the socket settings) decides whether logs leave the host. Where an intact remote copy exists, local erasure matters less.
Rate limiting (RateLimitIntervalSec= and RateLimitBurst=) decides whether a noisy event is fully recorded. During an incident, the bursts that matter are the ones most likely to be suppressed.
The failure that is not in the configuration
A host can be configured correctly and still lose its journal, because the directory was on a filesystem that did not mount, or on a partition that filled.
journald reacts to a full filesystem by rotating and discarding according to the cap. That behaviour is documented and correct, and it also means the last messages before a disk-fill event are the first to be removed.
A second, quieter path: a service that writes to standard output in a tight loop can consume the cap faster than an administrator expects, and the eviction is silent.
A review that matches operational use
Read the effective configuration, not the example file. systemd-analyze cat-config systemd/journald.conf shows what is actually applied, including drop-ins.
Confirm that /var/log/journal exists and is on a durable filesystem with monitoring on free space.
Size the cap against investigation requirements rather than against disk budget alone. Record the resulting retention in hours for a typical day, and re-check it after any traffic change.
Forward to a host that cannot be erased with the source. A local journal and a remote copy answer different questions.
Check the rate limits against the noisiest legitimate events. A limit tuned for routine operation is the wrong limit for the ten minutes that matter.
Limits
This is a logging-design discussion. Persistent, forwarded logs are a well-established control; the argument here is that the default configuration is a decision that is frequently left unmade.
References
journald.conf manual page, Storage and retention directives: https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html
systemd.exec manual page, standard output and the journal: https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html