Log retention and disk budgeting on a host: journald, logrotate and Windows event log sizing

What it is

Every log store on a host has a size limit, set differently per mechanism. journald.conf(5) documents SystemMaxUse= as the setting that caps how much disk space the persistent journal under /var/log/journal may use in total (default 10% of the file system, capped at 4G; the persistent limits apply only when /var/log/journal exists), with related settings SystemKeepFree= (default 15%, same cap), SystemMaxFileSize= and time-based MaxRetentionSec=/MaxFileSec= controlling rotation and age independently of size. logrotate.conf(5) documents maxage, which removes rotated log files older than a given number of days regardless of the rotate count also configured, so both a count and an age limit can apply together; the age is only checked when the log is rotated. On Windows, wevtutil sl <channel> /ms:<bytes> sets an event log's maximum size in bytes, per the wevtutil documentation, after which the log either wraps (overwrites oldest events) or requires manual clearing/archiving depending on the channel's configured retention behaviour.

Why it matters

A log store that fills silently either stops accepting new entries or starts overwriting old ones, either way losing exactly the evidence needed during an incident. Sizing these limits is a capacity-planning decision: too small and evidence disappears before anyone reads it; too large and logs compete with applications for disk space, which the disk-health article in this series addresses from the storage side.

Retention as a compliance or legal matter — how long specific record types must be kept, and under what access controls — is a decision for the organisation's own policy and, where applicable, its legal counsel; this article covers only the mechanical disk-budgeting settings, not what any regulation requires.

How to apply

• Set SystemMaxUse= in /etc/systemd/journald.conf (or a drop-in) to a fixed value appropriate to the partition, e.g. SystemMaxUse=2G, apply it with systemctl restart systemd-journald, and confirm current usage with journalctl --disk-usage; journalctl --vacuum-size=2G trims archived files immediately.
• For rsyslog- or application-written files rotated by logrotate, combine rotate <N> (keep N cycles) with maxage <days> in the relevant /etc/logrotate.d/ file so files are dropped by whichever limit is reached first.
• For Windows channels forwarded or kept locally, check current size and set a new cap non-interactively: wevtutil gl Security shows the current maxSize; wevtutil sl Security /ms:1073741824 (elevated prompt) sets it to 1 GiB; per the documentation, sizes are rounded to multiples of 64 KB, minimum 1 MB.
• Forward anything that must survive a host rebuild to a remote collector (see this series' articles on rsyslog and journald forwarding) rather than relying solely on local retention.

Pitfalls

• Assuming a large SystemMaxUse= means logs are kept forever; MaxRetentionSec= and disk pressure can still evict entries sooner.
• Setting a Windows log's mode to "overwrite as needed" without also forwarding it, which loses old events with no warning once the size cap is hit.
• Treating any of these settings as satisfying a retention requirement without checking what that requirement actually specifies.