/var full

[Paul Schmehl]

--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

# find /var/ -inum 27131920
/var/db/entropy/saved-entropy.6

# ls -lsa /var/db/entropy/saved-entropy.6
2 -r--------  1 operator  operator  2048 Jun 19 17:33 
/var/db/entropy/saved-entropy.6

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

Why is operator running dd?  Is it trying to fix the problem?

-- 
Paul Schmehl
As if it wasn't already obvious,
my opinions are my own and not
those of my employer.