Paul Schmehl wrote:
--On Thursday, June 19, 2008 20:02:59 +0200 Peter Boosten <[EMAIL PROTECTED]> 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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to