From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615
Description of problem:
Every week when logrotate rotates /var/log/mysqld.log it will attempt to restart
mysqld by sending a SIGHUP. mysqld disregards this and continues running. As a
result any new log entries will be written to the rotated mysqld.log.1 (and
mysqld.log.2 the next week etc.)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Make sure mysqld is running.
2. Wait for logrotate to rotate /var/log/mysqld.log at least once.
Actual Results: "fuser /var/log/mysqld.log*" shows mysqld is now using
Expected Results: "fuser /var/log/mysqld.log*" should show mysqld is using
This could be regarded as a bug in either /etc/logrotate.d/mysqld or
/usr/bin/safe_mysqld. /usr/bin/safe_mysqld runs mysqld with nohup, but
/etc/logrotate.d/mysqld attempts to kill mysqld with SIGHUP (and presumably
depends on safe_mysqld to restart it immediately).
I'm just copy-pasting my personal 'wall of notes'. Just to say that it's not
SIGHUP that should be used. May be of interest:
Rotation: Restarts and refreshes do not cause a new log file to be generated
(although it is closed and reopened). You can force MySQL to start using new
log files by using mysqladmin flush-logs or by using the SQL command FLUSH
LOGS. If you are using MySQL Version 3.21 you must use mysqladmin refresh.
To rotate stuff, you thus need a user who has 'reload' privileges,
which also include:
reload (re-read grant tables)
refresh (flush all tables and opens and closes the log
flush-privileges (same as reload)
flush-hosts (restricted functionality of reload)
flush-logs (restricted functionality of reload)
flush-tables (restricted functionality of reload)
Set up this user (called 'wheel') with no password. He can connect
INSERT INTO user SET
Now use the following log file:
daily ...run this every day
rotate 30 ...keep 30 files
create 660 mysql mysql ...on rotation, create a new
file with the given permissions/ownership
compress ...compress rotated files
delaycompress ...compress on next rotation
because the newly rotated file may still be written to
nomissingok ...complain if missing
ifempty ...rotate the file even if
it is empty
olddir query_dir ...rotate to 'olddir'
errors firstname.lastname@example.org ...mail to support if errors
nomail ...but don't mail any logs
if test -n "`ps acx|grep mysqld`"; then
/usr/local/mysql-3.23.52/bin/mysqladmin -u wheel flush-
logs ...flush the logs using mysqladmin
The notes here may be relevant to the query log but are not relevant to the
error log set in the [safe_mysqld] section of /etc/my.cnf, because mysqld
doesn't know anything about that file and therefore can't flush it. The way
output is redirected to that file is that the safe_mysqld script reads the
setting my my.cnf and redirects stderr to that file when starting mysqld.
Output remains redirected to that file even after mysql is told to flush its logs.
In short, as long as error logging is controlled by safe_mysqld rather than by
mysqld, telling mysqld to flush its logs, either by sending it a HUP (if that in
fact works) or by using mysqladmin, is not going to make the error log rotate
I suspect that the only way to rotate the error log is to restart mysqld.
Either that or to get this functionality moved into mysqld itself so that
safe_mysqld doesn't need to handle it.
I agree with jik that this is something that'd need refactoring between
safe_mysqld and mysqld. As such it doesn't seem appropriate for Red Hat
to do as a patch; the upstream MySQL developers would be the right people
to complain to. Please file a bug at www.mysql.com if this is still an issue.