Low free space on a Linux host stops writes before the system looks completely broken. Package installs stall, logs stop rotating, and applications that need temporary space can start failing as soon as the affected filesystem runs out of writable blocks.
The fastest cleanup path is to work from the filesystem inward. df confirms which mounted filesystem is actually full, du ranks the largest directories on that same filesystem, and find exposes the largest regular files inside the heavy subtree so removal targets are based on evidence instead of guesswork.
The example flow below uses current Ubuntu 24.04 conventions because package caches, logs, and retained journals commonly grow under /var on server systems. Most commands require sudo, lsof may need to be installed on minimal images, and the cleanup should stop when the large path belongs to live database files, container storage, virtual disks, or another application data directory that needs its own maintenance process.
$ df -hP /var Filesystem Size Used Avail Use% Mounted on /dev/vda2 59G 54G 2.6G 96% /
Run df against a path on the filesystem under pressure, such as /var, /home, or an application mount like /srv/data. Reuse the Mounted on value from this step in the later verification step.
$ sudo du -xhd1 /var 2>/dev/null | sort -hr 7.9G /var 4.8G /var/cache 1.9G /var/lib 1.1G /var/log 48M /var/backups ##### snipped #####
-x keeps the scan on the same filesystem, which avoids counting a different mount below the path. The next step should drill into the heaviest directory from this list instead of searching the whole system again.
$ sudo find /var/cache -xdev -type f -size +100M -printf '%s\t%p\n' 2>/dev/null | sort -n 125829120 /var/cache/app-export.tar 268435456 /var/cache/app-cache.bundle
Adjust the starting path and the -size threshold to match what the previous step exposed. Export archives, crash dumps, and stale installers are common cleanup targets, while active database or virtual machine files usually are not.
$ sudo rm -f /var/cache/app-export.tar
Move the file to another filesystem instead of deleting it when the data still needs to be kept but does not need to stay on the full mount.
rm removes the file immediately. Verify the path, owner, and application impact before using sudo.
$ sudo du -sh /var/cache/apt/archives 1.4G /var/cache/apt/archives $ sudo apt-get clean $ sudo du -sh /var/cache/apt/archives 12K /var/cache/apt/archives
apt-get clean removes retrieved package files from the local APT cache but leaves installed packages untouched. This step is worthwhile only when the earlier du scan shows that the cache is actually consuming meaningful space.
$ sudo lsof +aL1 / COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME tail 260 root 3r REG 0,82 8388608 0 855552 /var/log/app/service.log (deleted)
Replace / with the mount point from the first step when the full filesystem is not the root filesystem. Space from a deleted file is not returned until the owning process closes the descriptor.
$ sudo journalctl --disk-usage Archived and active journals take up 1.2G in the file system. $ sudo journalctl --rotate --vacuum-time=7d
journalctl --disk-usage shows the current journal footprint, and --vacuum-time=7d removes archived journal files older than seven days after the rotation step makes the current journal eligible to archive. Skip this step if the host does not use persistent systemd journals or if /var/log/journal was not one of the large directories.
Vacuuming the journal reduces the amount of historical log data available for later troubleshooting or forensic review.
$ df -hP /var Filesystem Size Used Avail Use% Mounted on /dev/vda2 59G 46G 10G 83% /
If Use% barely changes, stop deleting files blindly and return to the investigation path to identify another heavy subtree or filesystem-specific overhead source.