Linux admins often watch CPU load, memory use, and uptime. Those metrics matter. However, disk usage causes more outages than many teams expect. One directory deserves special attention: /var.
If /var grows without control, it can quietly damage system stability and even crashes your Linux server. In this tutorial, I will explain why ignoring /var can break a Linux server without warning and how to monitor the /var directory to prevent disk issues and service failures.
Table of Contents
What /var Is and Why It Matters
The /var directory stores data that changes while the system runs. This includes:
- Logs
- Databases
- Caches
- Spool files
- Runtime state
Because this data keeps growing, /var needs regular checks. When admins ignore it, problems appear without warning.
Logs Grow Faster Than You Think
Most system and service logs live in:
/var/log/var/log/journal(when systemd uses persistent storage)
Services write logs all the time. Over time, even normal logging can fill gigabytes of space. Debug logging makes this worse. If log rotation breaks or retention rules are too loose, disk usage climbs fast.
This risk increases when /var shares space with the root filesystem. In that case, one noisy service can fill the entire disk.
What Happens When /var Fills Up
A full /var does not always crash a system. Still, it often causes serious trouble. Here is what really happens.
Logging Stops Working
When disk space runs out, systemd cannot write new journal entries. As a result, you lose logs right when you need them most. Troubleshooting becomes harder and slower.
Databases May Fail
Many databases store data under /var/lib by default. Examples include MySQL, MariaDB, and PostgreSQL. If /var fills up and the database lives there, write operations fail. Transactions break. In some cases, the database stops.
This does not happen if the database uses another filesystem. Layout matters.
Applications Become Unstable
Applications often write logs, state files, and cache data under /var. When disk space disappears, behavior changes. Some apps crash. Others slow down or return errors. Each app reacts differently, which makes diagnosis harder.
SSH Still Works, but With Limits
SSH does not stop accepting connections just because /var/log is full. However, it may fail to write login records or authentication logs. In extreme disk exhaustion cases, related failures can affect remote access. Still, /var being full alone does not kill SSH.
Why This Can Lead to Downtime
A full /var often leads to downtime when:
- It shares space with
/ - Critical services depend on it
- No disk alerts exist
Not every system fails the same way. However, disk exhaustion always increases risk. That makes prevention essential.
Essential Linux Commands to Monitor and Control /var Disk Usage
You do not need complex monitoring systems to control /var. A few well-chosen commands and habits prevent most disk-related incidents. Use these tools regularly.
Note: All Commands below require root or sudo permission.
1. Find what is growing inside /var
Start by locating the biggest space users.
du -h --max-depth=1 /var | sort -h
This command shows directory sizes in a clear order. It helps you spot problems fast, such as oversized logs or runaway caches.
Sample Output:
4.0K /var/local
4.0K /var/opt
92K /var/tmp
6.9M /var/backups
7.3M /var/spool
82M /var/mail
4.0G /var/log
8.2G /var/lib
19G /var/cache
31G /var
For a deeper view:
du -h --max-depth=1 /var/log | sort -h
This focuses only on logs, which are the most common cause of disk pressure.
2. Check filesystem usage, not just directory size
Sometimes space runs out due to reserved blocks or inode exhaustion.
df -h /var
Sample Output:
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p2 456G 273G 161G 63% /
This shows total space, used space, and free space.
df -i /var
This checks inode usage. Millions of tiny files can break a system even when disk space looks fine.
Recommended Read: Disk Space Analysis Made Easy: Understanding df And du Commands In Linux
3. Monitor systemd journal size and limits
Systemd journals often grow quietly.
journalctl --disk-usage
To limit future growth:
journalctl --vacuum-size=500M
Or clean old entries by age:
journalctl --vacuum-time=14d
These commands reduce disk usage without stopping logging.
4. Verify log rotation is actually working
Logrotate exists on most systems, but it does nothing if misconfigured.
logrotate -d /etc/logrotate.conf
This runs logrotate in debug mode and shows what it would do.
logrotate -f /etc/logrotate.conf
This forces rotation. Use it when logs already grew too large.
Also confirm that rotation runs on schedule:
systemctl status logrotate.timer
5. Watch for deleted files still using space
A common hidden issue occurs when a process keeps a deleted file open.
lsof +L1
This shows files deleted from disk but still consuming space. Restarting the related service usually frees the space instantly.
6. Inspect database and service data
Large services often live under /var/lib.
du -sh /var/lib/*
This quickly reveals growing databases, container data, or package state.
If you run containers:
du -sh /var/lib/docker
or
du -sh /var/lib/containers
Containers often grow faster than logs.
7. Clean package manager caches safely
Package caches can grow over time.
On Debian and Ubuntu:
apt autoremove
apt clean
On RHEL, CentOS, and Rocky Linux:
dnf clean all
These commands free space without breaking the system.
8. Add simple disk alerts
Even basic alerts prevent emergencies.
For a quick manual check:
df -h | grep /var
For automation, add a cron job or monitoring rule that warns when usage crosses 70–80%. Early warnings give you time to act calmly.
Conclusion
Most Linux outages do not start with high CPU or memory spikes. They start quietly. A log grows faster than expected. A cache never clears. A database writes one file too many. All of this happens in one place: /var.
When the /var directory fills up, systems lose logs, services fail, and recovery becomes harder. That is why experienced Linux admins watch /var before problems appear.
Using these practical Linux commands, you can efficiently track logs, journals, and service data under /var and prevent disk exhaustion and even server crash.
These simple command line tools turn silent growth into visible signals. Run them often. Alert early. You avoid outages and late-night recovery work.
Recommended Read:
- Good Alternatives To du Command To Check Disk Usage In Linux
- Filelight – Visualize Disk Usage On Your Linux System
- Duc – A Collection Of Tools To Inspect And Visualize Disk Usage
- How To Visualize Disk Space Usage With Vizex In Linux
- How To View Disk Usage With Duf On Linux And Unix
- How To Check Disk Space Usage In Linux Using Ncdu
- Check Disk Space Using Agedu In Linux
