The strange thing to me is that system logs have a limit by default, according to the man pages for journald. I'm sure there's some reason I'm overlooking that allows them to get out of hand, but I feel like the default should be changed from percentage based (which is the default for journald) to fixed size on a desktop-focused distribution where the odds of a user needing multiple gigs of log files is extremely low.
According to the manual page, logs on disk should normally be capped at 4G, no matter how large the file system is. I can't fathom needing that much. You can edit /etc/systemd/journald.conf to uncomment SystemMaxSize and RuntimeMaxSize and set them to 200M to limit logs to 200 MB in size, which should keep them small. You can also uncomment MaxRetentionSec and set it to 1w which will delete logs after they're a week old. 1m holds for up to a month, if that's more comfortable.
Step by step, that'd be:
sudo nano /etc/systemd/journald.conf- Use the arrow keys to find the lines that start with a # and the names above (
SystemMaxSize,RuntimeMaxSize,MaxRetentionSec). - Delete the # in front of any line you want to change.
- After the name, put
=200Mfor the size options, or=1wfor the retention option (or longer if preferred). - Press Ctrl-O to save changes.
- Press Ctrl-X to close the text editor.
- Reboot, so the changes are loaded, or do
systemctl restart systemd-journald.service
With the example sizes I gave above, the lines in question would look like this:
SystemMaxUse=200M
RuntimeMaxUse=200M
MaxRetentionSec=1w
All that said, I agree that it shouldn't be possible with defaults for a user to get their system to an unbootable state due to lack of HDD space unless the user has overridden a default. By the same token, I think it's important that the user be able to override defaults, even at risk to their system, if they explicitly choose to. A lot of us are here because we're tired of Microsoft telling us how our computers should behave, after all.