Bug 72391 - logrotate fails to restart mysqld when rotating mysqld.log
logrotate fails to restart mysqld when rotating mysqld.log
Status: CLOSED UPSTREAM
Product: Red Hat Raw Hide
Classification: Retired
Component: mysql (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Lane
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-23 09:56 EDT by Need Real Name
Modified: 2013-07-02 22:59 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-30 14:16:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2002-08-23 09:56:46 EDT
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).
Comment 1 Trond Eivind Glomsrxd 2002-08-27 11:58:50 EDT
Reproduced.
Comment 2 David Tonhofer 2002-10-16 12:17:30 EDT
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@m-plify.com                   ...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
  }
Comment 3 Jonathan Kamens 2002-11-15 12:26:04 EST
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.
Comment 4 Tom Lane 2005-09-30 14:16:38 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.