/var full — the journal or logs have consumed the disk
systemd-journald and application logs have filled /var, and services start failing in ways that have nothing obvious to do with disk space.
What you see
Databases refuse writes, services fail to start, sudo may misbehave. df shows /var at 100%.
What is actually wrong
No journal size cap set, logrotate not running or misconfigured, or a single application logging at debug level indefinitely.
Codes and articles
The fix
Reclaim the space and cap it permanently
/var is full. Do the capping step as well as the clearing step, or you will be back here in a month.
Confirm where the space has gone.
df -h /varsudo du -xh /var --max-depth=2 2>/dev/null | sort -rh | head -15
Check how much the journal is holding.
journalctl --disk-usageTrim it immediately to reclaim space.
sudo journalctl --vacuum-size=200MOr trim by age instead.
sudo journalctl --vacuum-time=7dCap it permanently so this cannot recur — set SystemMaxUse=500M in /etc/systemd/journald.conf.
sudo sed -i 's/^#\?SystemMaxUse=.*/SystemMaxUse=500M/' /etc/systemd/journald.confsudo systemctl restart systemd-journald
With no cap, journald will use up to 10% of the filesystem. On a large /var that is a lot of logs and on a small one it is enough to fill it.
Check logrotate is actually running and not failing silently.
systemctl status logrotate.timersudo logrotate -d /etc/logrotate.conf 2>&1 | tail -30
Find any single enormous log file that logrotate is not covering.
sudo find /var/log -type f -size +100M -exec ls -lh {} \;
df -h /var && journalctl --disk-usageWhere this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.