Random 500s, failed deploys, or services refusing to restart? A full root filesystem (/) often shows up exactly like that. This guide walks through a fast triage and the highest-impact cleanup steps so you can reclaim space without breaking the stack.
Quick triage
- Confirm usage:
df -h - Identify largest offenders (Ubuntu GNU
dusupports both forms):sudo du -xhd1 / | sort -hsudo du -xh --max-depth=1 / | sort -h
- Drill into suspects:
sudo du -xhd1 /var | sort -hsudo du -xh --max-depth=1 /var | sort -h
Common high-impact cleanup targets
1) Logs
- Check:
/var/log - Rotate or compress properly; avoid deleting active logs blindly.
2) Package cache
- Clear safely:
sudo apt clean
3) Old kernels
- Confirm running kernel first:
uname -r - Check installed:
dpkg --list | grep linux-image - Remove old kernels carefully; keep the current one plus one fallback.
- Example (only after confirming it’s not the running kernel):
sudo apt remove linux-image-5.4.0-99-generic
- Example (only after confirming it’s not the running kernel):
4) Orphaned packages
- Remove unused dependencies:
sudo apt autoremove
Validate services after cleanup
- Apache:
sudo systemctl status apache2 --no-pager - PHP-FPM:
sudo systemctl status php*-fpm --no-pager
FAQ
What’s the first thing to check when the disk is full?
Run df -h to confirm which filesystem is full, then sudo du -xhd1 / | sort -h to see which top-level directories use the most space. Usually /var (logs, caches, WordPress) is the main culprit.
Is it safe to run apt clean on a production server?
Yes. It only removes downloaded package files from the local cache. It does not remove installed software or configs.
Should I remove all old kernels?
Keep the currently running kernel and at least one older one as a fallback. Remove only kernels you’ve confirmed are not in use.
Related
- Ubuntu upgrade cleanup checklist — post-upgrade hygiene
- Apache + PHP-FPM stability basics — confirm services after cleanup