/var full

[Peter Boosten]

Paul Schmehl wrote:
> --On Thursday, June 19, 2008 20:02:59 +0200 Peter Boosten 
> <peter at boosten.org> wrote:
> 
>> Paul Schmehl wrote:
>>>>
>>>>>  I'm leaning toward some sort of bug in mysql version 5.0.51 which
>>>>> creates a temporary file (in the wrong place) and then doesn't
>>>>> release it until it exhausts the space on the drive.  In any case,
>>>>> I'm going to report it to the mysql folks as such and hope they can
>>>>> figure out what the cause is.
>>>>
>>
>> try to find the file with
>> # fstat | grep var
>>
>>
>> This will give a list with inodes for open files (the 6th column).
>>
>> # find /var -inum <inode>
>>
> 
> Interesting.
> 
>> From the last section of entries in dmesg.today:
> 
> pid 73721 (dd), uid 2 inumber 27131920 on /var: filesystem full
> pid 730 (mysqld), uid 88 inumber 27132148 on /var: filesystem full
> 
> # find /var/ -inum 27132148
> /var/db/mysql/buttercup3-bin.000031
> 
> # ls -lsa /var/db/mysql/buttercup3-bin.000031
> 15856 -rw-rw----  1 mysql  mysql  16208184 Jun 19 03:28 
> /var/db/mysql/buttercup3-bin.000031

Do you replicate this mysql server to another?

If not, comment the log-bin directive in my.cnf.
That'll take care of these binary logfiles.

Peter
> 
> So it could have been something else entirely, and when those files 
> tried to write to /var it was already full?
> 

My first thought: mysql is just reporting something wrong, but isn't
actually causing it.

I've seen a partition filling up once by a deleted, yet open apache
log file. No df nor du reported a full disk, yet it was. Restarting
apache did the trick.

Peter

-- 
http://www.boosten.org