After logrotate rotates the mysqld.err logfile, it sends a HUP signal to mysqld. It appears that mysqld is ignoring this thus it doesn't switch to the new mysqld.err. Running lsof & checking /proc/$PID explains a little more what is going on: lsof: mysqld <snip> /var/log/mysql/mysqld.err-20131127 (deleted) /proc: l-wx------ 1 root root 64 Nov 28 11:32 /proc/18314/fd/1 -> /var/log/mysql/mysqld.err-20131127 (deleted) /var/log/mysql: -rw-rw---- 1 mysql mysql 6.8M Nov 27 03:07 mysqld.err-20131127.gz -rw-rw---- 1 mysql mysql 0 Nov 27 03:10 mysqld.err After opening both the current logfile where the fd points to and the gziped old log, I couldn't find a server status report as expected, so I can assume that either mysqld never received the signal or it ignored it Logfile directory and all logfiles belong to the mysql user and the mysqld.pid file is in place (/var/run/mysqld/mysqld.pid). Since mysqld.err has zero size, logrotate won't attempt to rotate again, so disks start filling up (if this is a busy server). This happened after upgrading two very busy mysql servers from 5.5.28 to 5.5.29. After realising what went on, I restarted both servers but the same thing happened on the next rotation. Note: I have another mysql 5.5.29 server with significantly less load, which rotates just fine. Possible solution to this would be to run FLUSH LOGS on postrotate like other distros do as when mysqld receives a SIGHUP, it flushes tables, logs etc[0]. Even if it is a mysql bug, this could be a workaround to it. [0] https://dev.mysql.com/doc/refman/5.5/en/server-signal-response.html Reproducible: Sometimes kernel: Linux sql 3.4.52-gentoo #3 SMP x86_64 Intel(R) USE="community perl profiling ssl -cluster -debug -embedded -extraengine -jemalloc -latin1 -max-idx-128 -minimal (-selinux) -static -systemtap -tcmalloc {-test}"
*** This bug has been marked as a duplicate of bug 476202 ***
