var is full but I can't find the files

Q

questions

My server is telling me that var is full but I only have 700mb of file in a 24GB partition...

Can anyone help me find the other 22GB of files that are filling up my var directory? I've gone through each and every file but as I delete files (mostly logs) it just fills up again... I still have only EVER had about 800M of files...
Code: 
# cd /var
# du -h

767M	.


# df -h
Filesystem       Size    Used   Avail Capacity  Mounted on
/dev/twed0s1a    869G    217G    583G    27%    /
devfs            1.0K    1.0K      0B   100%    /dev
/dev/twed0s1d    1.9G    128K    1.8G     0%    /tmp
[B]/dev/twed0s1e     24G     22G   -176K   100%    /var[/B]
procfs           4.0K    4.0K      0B   100%    /proc

help?
 
I have a similar problem:

My server is telling me that var is full but I only have 700mb of file in a 24GB partition...

Can anyone help me find the other 22GB of files that are filling up my var directory? I've gone through each and every file but as I delete files (mostly logs) it just fills up again... I still have only EVER had about 800M of files...
Code: 
# cd /var
# du -h

767M .


# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/twed0s1a 869G 217G 583G 27% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/twed0s1d 1.9G 128K 1.8G 0% /tmp
/dev/twed0s1e 24G 22G -176K 100% /var
procfs 4.0K 4.0K 0B 100% /proc

help?
 
Isn't it great how talking to yourself fixes the problem. I restarted MySQL and now I'm down to just 4% usage of /var
Code: 
# /usr/local/etc/rc.d/mysqld restart
Stopping mysqld: [ OK ]
Starting mysqld: [ OK ]
# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/twed0s1a 869G 217G 583G 27% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/twed0s1d 1.9G 130K 1.8G 0% /tmp
/dev/twed0s1e 24G 796M 21G 4% /var
procfs 4.0K 4.0K 0B 100% /proc
 
Please don't post the same question to multiple threads. Once is enough.

Keep in mind that if an application has a file open, if you remove that file the space will not be reclaimed until you restart the application. This is because the application still has a filehandle open on that file.
 
Usually, the cause for this is Apache logs, Apache logs particularly error_log can pile up quickly, and even if you delete the offensive log file, and it doesn't show in a directory listing, you have to restart apache, in order for the file to be released and the space made available. You probably should fix the bad code that is filling your error_log up so fast as well.:stud
 
SirDice said:
Please don't post the same question to multiple threads. Once is enough.

Keep in mind that if an application has a file open, if you remove that file the space will not be reclaimed until you restart the application. This is because the application still has a filehandle open on that file.
Click to expand...

Thanks for the warm welcome and being no help at all answering my question. The solution was to restart mysql.
 
jnbek said:
Usually, the cause for this is Apache logs, Apache logs particularly error_log can pile up quickly, and even if you delete the offensive log file, and it doesn't show in a directory listing, you have to restart apache, in order for the file to be released and the space made available. You probably should fix the bad code that is filling your error_log up so fast as well.:stud
Click to expand...

It wasn't related to apache nor any error logs (except that mysql is initated by a web site), it was related to mysql and possibly the main access log... it wasn't writing the error log to a file for some reason.
 
Well, I did say, Usually ;-). MySQL is also a frequent offender for the problem you describe, however, Apache is exponentially higher in occurrences of /var full problems, hence my choice to use it, either way, the solution was the same, restart the offensive daemon. That said, enjoy an exquisite day/evening/night, as applicable.
 
You must log in or register to reply here.
Back
Top