apt-get clean to remove cached .deb packages and rotate logs with journald or manual deletion in /var/log. This resolves the critical storage bottleneck without requiring complex partition resizing.
Identifying the Culprits
The first step in troubleshooting a full /var partition is to understand what is consuming the space. Because /var is mounted separately, filling it up does not necessarily affect your root filesystem, but it can prevent services from writing new data, causing application failures or system instability. You need to pinpoint the specific subdirectories that are growing uncontrollably.
Start by checking the overall usage of the partition using the df -h command. This will confirm that /var is indeed at 100% capacity. Once confirmed, drill down into the directory structure. The most common offenders are typically located in /var/cache/apt, /var/log, /var/lib/docker, or /var/mail.
To see which directories are using the most space, use the du command with human-readable output. Run the following command to get a summary of the top-level directories under /var:
sudo du -sh /var/* | sort -hrThis command lists the size of each immediate subdirectory, sorted by size in descending order. If you find a specific folder like /var/lib/docker or /var/cache/apt taking up gigabytes, you have identified your primary target for cleanup. For a more granular view, you can recursively check deeper levels, such as sudo du -sh /var/log/* | sort -hr.
Cleaning Package Manager Cache
In Debian-based systems, the APT package manager stores downloaded installation files in /var/cache/apt/archives. Over time, this directory can accumulate hundreds of megabytes or even gigabytes of old .deb files that are no longer needed because the packages are already installed. This is often the easiest and safest place to reclaim significant space.
To clear this cache, run the following command:
sudo apt-get cleanThis command removes all files from the /var/cache/apt/archives directory except for the lock file. It does not uninstall any software; it only deletes the installer packages. If you want to be slightly more conservative and keep the most recent versions of packages, you can use sudo apt-get autoclean instead, which only removes obsolete package files. After running the clean command, verify the freed space with df -h /var.
If you frequently install and remove packages, consider configuring APT to automatically clean the cache after each operation. Add the line D::Keep-Downloaded-Packages "0"; to /etc/apt/apt.conf.d/99clean-cache. This ensures that future updates do not contribute to the bloat. For more details on managing disk space, see our guide on resolving /var full issues.
Managing Log Files
Log files in /var/log are another major contributor to disk space exhaustion. Services like Nginx, Apache, Postfix, and the systemd journal write continuously to these files. Without proper rotation policies, these files can grow indefinitely until they fill the partition.
First, check if journald is storing excessive data. The systemd journal can be configured to limit its size. Edit the /etc/systemd/journald.conf file and ensure the following settings are present:
SystemMaxUse=50M
RuntimeMaxUse=10MAfter making changes, restart the journal service with sudo systemctl restart systemd-journald. This forces the journal to truncate old entries and adhere to the new size limits. Additionally, you can manually vacuum the journal to immediately free up space using sudo journalctl --vacuum-size=50M.
For traditional log files, ensure that logrotate is configured correctly. Check the configuration files in /etc/logrotate.d/. If you find specific service logs that are not being rotated, you may need to add a custom rotation rule. For example, if you have large Nginx access logs, ensure they are included in the logrotate configuration. Manually deleting logs (e.g., sudo rm /var/log/largefile.log) should be done cautiously, as some services hold file descriptors open. Instead, truncate them using sudo truncate -s 0 /var/log/largefile.log to preserve the file handle while clearing the content.
Handling Docker and Application Data
If your server runs Docker, /var/lib/docker can become a massive sinkhole for disk space. Images, containers, volumes, and build caches accumulate rapidly. To identify unused resources, run docker system df to see a breakdown of space usage.
To safely remove stopped containers, unused networks, and dangling images, execute:
docker system pruneThis command prompts for confirmation before removing objects. Be careful not to remove running containers or essential volumes unless you are certain they are no longer needed. For a more aggressive cleanup, including build cache, use docker system prune --all --volumes. However, this is destructive and should only be used when you are sure you can rebuild your environment if necessary.
Other applications may also store temporary data in /var/tmp or /var/spool. Review these directories periodically. For instance, /var/spool/postfix might contain queued emails if your mail server is experiencing delivery issues. Cleaning these queues requires specific commands depending on the MTA, such as postsuper -d ALL for Postfix.
Preventing Future Issues
Once you have reclaimed space, implement monitoring to prevent recurrence. Set up alerts using tools like Nagios, Zabbix, or simple cron jobs that check disk usage via df and send an email if /var exceeds 80% capacity. This proactive approach allows you to address growth trends before they cause outages.
Consider implementing automated cleanup scripts for known bloat sources. For example, a weekly cron job that runs apt-get clean and docker system prune can keep the system healthy without manual intervention. Regularly review the growth rate of your log files and adjust logrotate thresholds accordingly. If your application generates substantial data, consider archiving older logs to external storage or a centralized logging server like ELK Stack or Graylog, rather than keeping them locally on the /var partition.
Frequently Asked Questions
Can I delete files in /var/lib/dpkg/info?
No, you should never manually delete files in /var/lib/dpkg/info. This directory contains metadata required by the APT package manager to track installed packages. Deleting these files can corrupt your package database and prevent future installations or updates. Always use apt-get commands to manage packages.
Why is /var/log/syslog so large?
A large syslog file usually indicates verbose logging enabled by default or a misconfigured service generating excessive debug messages. Check the configuration of your syslog daemon (rsyslog or syslog-ng) and reduce the log level for non-critical services. Also, ensure that logrotate is properly configured to compress and archive old syslog entries.
How do I find hidden large files in /var?
Use the find command to locate files larger than a specific threshold. For example, to find files larger than 100MB in /var, run: sudo find /var -type f -size +100M. This helps identify unexpected large files that might not be obvious from standard directory summaries.
What if /var is full due to deleted files still held open?
If you delete a large log file but the space doesn't free up, a process might still have the file open. Use lsof +L1 to list deleted files that are still held open by processes. Restarting the affected service will release the file descriptor and free the space.
Is it safe to mount /var on a larger partition later?
Yes, but it requires careful planning. You must ensure the new partition is formatted and ready, then move data, update /etc/fstab, and remount. Refer to our guide on fixing boot issues after partition changes to avoid breaking your system during the transition.