A monitoring box paged me about a full root partition this week, and the culprit was the systemd journal. /var/log/journal had quietly grown to several gigabytes on a machine with a small disk, and nothing had been rotating it the way I'd lazily assumed something would. So this is the short version of how journald decides how much disk to use, and how to tell it to behave.
The first thing to know is that the journal has two modes. Volatile storage keeps logs in /run, in memory, and they vanish on reboot. Persistent storage writes to /var/log/journal and survives. Many distributions ship with Storage=auto, which means "be persistent if the directory exists, volatile otherwise." On this box the directory existed, so it had been dutifully persisting everything since install, and the default size cap is generous: by default journald will use up to 10% of the filesystem, which on a small partition is plenty to cause trouble.
Check what you've actually got:
journalctl --disk-usage
To reclaim space right now, you can vacuum by size or by age without touching config:
journalctl --vacuum-size=200M
journalctl --vacuum-time=2weeks
That trims the existing logs immediately. But it doesn't stop the growth coming back, so the real fix lives in /etc/systemd/journald.conf. The three knobs that matter:
[Journal]
SystemMaxUse=200M
SystemKeepFree=1G
SystemMaxFileSize=50M
SystemMaxUse is the hard ceiling on total journal size. SystemKeepFree tells journald to always leave at least that much free on the filesystem, which is the safety net that actually matters when other things share the disk. SystemMaxFileSize caps individual journal files so rotation happens in sensible chunks rather than one enormous file. Reload to apply:
systemctl restart systemd-journald
The thing I'd genuinely missed, and the reason I'm writing this down, is that journald's defaults are reasonable for a machine with a big disk and quietly hostile for a small one. Ten percent of a 500GB array is fine. Ten percent of a 16GB root partition, plus a chatty service logging every health check, fills up faster than you'd think and then everything that needs to write to disk starts failing in confusing ways.
If you genuinely don't want persistent logs on a given box, the cleaner answer is to set Storage=volatile and let them live in RAM. But on anything I might need to debug after a crash, I'd rather keep the history and just cap it. A 200MB journal has saved me far more time than it costs in disk.