The systemd journal is bounded (SystemMaxUse)
Set an explicit ceiling on the systemd journal (SystemMaxUse) so /var/log/journal can never fill its filesystem. This is a pavois-native control from the growth-* family: any filesystem pavois carves out must carry a mechanism that stops it from filling. The check asserts the rotation policy, never the free space of the day, because free space is a snapshot while a bound is a guarantee.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
What Pavois checks
Pavois runs systemd-analyze cat-config systemd/journald.conf and keeps the last SystemMaxUse= line, which is the effective value: that command merges the vendor file, /etc/systemd/journald.conf and every drop-in under journald.conf.d/, in systemd's own precedence order. Grepping /etc/systemd/journald.conf alone would miss a drop-in that overrides (or removes) the bound, and would report compliant on a journal that is in fact unbounded. Any non-empty size value (1G, 500M, ...) passes: the control demands that a ceiling exists, and does not dictate its size.
describe command('systemd-analyze cat-config systemd/journald.conf 2>/dev/null | grep -iE "^[[:space:]]*SystemMaxUse[[:space:]]*=" | tail -1') do
its('stdout') { should match(/=\s*\d+[KMG]?/i) }
endHow to verify it is applied
Read the resolved value, then the real disk usage:
systemd-analyze cat-config systemd/journald.conf | grep -i '^SystemMaxUse'
journalctl --disk-usage
The reported archive size must stay under the declared ceiling. journalctl --verify confirms the journal files themselves are intact after a vacuum.
Inspect & investigate
journald reports its own enforcement: journalctl -u systemd-journald shows lines such as System Journal (/var/log/journal/...) is 1.0G, max 1.0G, 0B free and Vacuuming done, freed 512.0M of archived journals. Seeing those lines is the proof the bound is not merely configured but actively applied.
Remediation
Pavois writes a dedicated drop-in /etc/systemd/journald.conf.d/99-pavois-bounded.conf (root:root, 0644) containing:
[Journal]
SystemMaxUse=1G
SystemKeepFree=500M
MaxRetentionSec=90day
Three complementary bounds: a hard size ceiling, a floor of free space journald must leave to the rest of the filesystem, and a retention horizon. The drop-in holds only this setting, so no other control can silently overwrite it. Apply it with confkit harden apply; journald picks it up on systemctl restart systemd-journald.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| content | [Journal] SystemMaxUse=1G SystemKeepFree=500M MaxRetentionSec=90day |
|---|---|
| group | root |
| mode | 0644 |
| owner | root |
| path | /etc/systemd/journald.conf.d/99-pavois-bounded.conf |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
The growth-* family exists because of a real outage: a pavois-hardened host powered itself off six seconds into every boot. max_log_file_action = keep_logs (auditd never deletes a log), plus a separate /var/log/audit partition (created by the pavois recipe), plus admin_space_left_action = halt filled the filesystem (measured: 738 files, 5.8 GB, 100%), and every control was green. Bounding the journal applies the same lesson to /var/log. The trade-off is real: past the ceiling, the oldest entries are dropped. Size SystemMaxUse against your actual retention requirement, and if you must keep everything, ship the journal to a SIEM rather than raising the bound.