From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3 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): How reproducible: Always 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 mysqld.log.1. Expected Results: "fuser /var/log/mysqld.log*" should show mysqld is using mysqld.log. Additional info: 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).
Reproduced.
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 files) 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 from localhost: INSERT INTO user SET Host='localhost',User='wheel',Password='',Select_priv='N',Insert_priv='N', Update_priv='N',Delete_priv='N',Create_priv='N',Drop_priv='N',Reload_priv='Y',Sh utdown_priv='N', Process_priv='N',File_priv='N',Grant_priv='N',References_priv='N',Index_priv='N' ,Alter_priv='N'; Now use the following log file: /var/log/mysql-3.23.52/query_log { 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 support ...mail to support if errors nomail ...but don't mail any logs postrotate 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 fi endscript }
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 properly. 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.