Results 1 to 3 of 3
Hi,
When I run df -h it gives me this
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 950M 336M 566M 38% /
varrun 3.9G 64K 3.9G 1% /var/run
varlock ...
- 11-14-2011 #1Just Joined!
- Join Date
- Nov 2011
- Posts
- 1
Finding the large files in /var
Hi,
When I run df -h it gives me this
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 950M 336M 566M 38% /
varrun 3.9G 64K 3.9G 1% /var/run
varlock 3.9G 0 3.9G 0% /var/lock
udev 3.9G 32K 3.9G 1% /dev
devshm 3.9G 0 3.9G 0% /dev/shm
/dev/sda5 4.7G 382M 4.3G 9% /usr
/dev/sda6 4.7G 4.1G 655M 87% /var
/dev/sda7 920G 16G 904G 2% /home
none 3.9G 1.1G 2.9G 28% /tmp
As you can see the /var usage is 87%. So I wanted to see why.
I then tried to look in /var like so
/var# du -hx --max-depth=1
2.7M ./backups
105M ./cache
63M ./lib
0 ./local
0 ./lock
0 ./mail
0 ./opt
0 ./run
8.0K ./spool
3.4M ./log
0 ./tmp
1.4G ./www
1.6G .
I'm not sure how in the du -hx --max-depth=1 version above it gives a file size of 1.6g but in the first command (df -h) it says the var directory has a file size of 4.1g.
Help would be much appreciated...
Here's some more background
A few days ago I had a high Usage for the /Var just like above. So I tried to remove the .gz files under the apache2 directory.
Somehow instead I managed to remove all of the files in the apache2 directory. BUT the usage size for /var still did not go down.
I have since reinstated the apache2 log files and they are not populating.
- 11-18-2011 #2Linux Guru
- Join Date
- Apr 2009
- Location
- I can be found either 40 miles west of Chicago, or in a galaxy far, far away.
- Posts
- 8,970
Look in /var/log - that's where all the system log files go, and it is probable that this is your source of /var file system usage. You can clear out old log files without much (or any) system reliability issues.
Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!
- 11-19-2011 #3Just Joined!
- Join Date
- Sep 2011
- Posts
- 14
Look for a misbehaving service daemon writing constantly to a log file. Most likely in /var/log as stated above. I had this happen a while back with gpm for instance, when my usb mouse started having intermittent connection problems. Try this:
If that doesn't find it specifically, do this instead to search all of /var:Code:du -hc $(find /var/log -type f)
Like I said, my best guess is a misbehaving service daemon. When you find it, you need to either disable it completely or preferably fix it.Code:du -hc $(find /var -type f)


Reply With Quote