logrotate not rotating the logs

Question

I have this logrotate config and I am running on Ubuntu 10.04.

/var/log/mysql/mysql-slow.log {
    daily
    rotate 3
    compress
    notifempty
    missingok
    create 660 mysql adm
    postrotate 
    if test -x /usr/bin/mysqladmin && \
       /usr/bin/mysqladmin  ping &>/dev/null
    then
       /usr/bin/mysqladmin  flush-logs
    fi
endscript

}

I put this in /etc/logrotate.d yesterday and today the log was not rotated.

Below are the things that I have done:

1. I verified that the log is indeed in /var/log/mysql/mysql-slow.log
2. mysqladmin lines work fine when run as root
3. mysql is able to write to the mysql-slow.log

When I did this:

$ logrotate -d -f mysql-slow

reading config file mysql-slow
reading config info for /var/log/mysql/mysql-slow.log 

Handling 1 logs

rotating pattern: /var/log/mysql/mysql-slow.log  forced from command line (3 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/mysql/mysql-slow.log

log needs rotating
rotating log /var/log/mysql/mysql-slow.log, log->rotateCount is 3
dateext suffix '-20120329'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
renaming /var/log/mysql/mysql-slow.log.3.gz to /var/log/mysql/mysql-slow.log.4.gz     (rotatecount 3, logstart 1, i 3), 
renaming /var/log/mysql/mysql-slow.log.2.gz to /var/log/mysql/mysql-slow.log.3.gz (rotatecount 3, logstart 1, i 2), 
renaming /var/log/mysql/mysql-slow.log.1.gz to /var/log/mysql/mysql-slow.log.2.gz (rotatecount 3, logstart 1, i 1), 
renaming /var/log/mysql/mysql-slow.log.0.gz to /var/log/mysql/mysql-slow.log.1.gz (rotatecount 3, logstart 1, i 0), 
renaming /var/log/mysql/mysql-slow.log to /var/log/mysql/mysql-slow.log.1
creating new /var/log/mysql/mysql-slow.log mode = 0660 uid = 20004 gid = 4
running postrotate script
running script (multiple) with arg /var/log/mysql/mysql-slow.log : " 
    if test -x /usr/bin/mysqladmin && \
       /usr/bin/mysqladmin &>/dev/null
    then
       /usr/bin/mysqladmin flush-logs
    fi
"
compressing log with: /bin/gzip
removing old log /var/log/mysql/mysql-slow.log.4.gz

1. Where is the log that shows that logrotate was successful? I want to see if there is anything that would say that there was a problem.
2. Any ideas on why the logrotate is not working?

Answer 1

A common issue is when you first setup a daily logrotate.d entry, it will not rotate the first day. When you use a time based rotation (daily/weekly/monthly) logrotate scribbles a date stamp of the last date it saw the file in /var/lib/logrotate/status (or /var/lib/logrotate.status on RHEL systems).

The scribbled date becomes the reference date from that future runs of logrotate will use to compare 'daily' rotations. Since the default cron job runs daily, this is typically only a problem in daily jobs.

You can avoid this problem two ways;

1. run sudo logrotate -f /etc/logrotate.d/<my rotate job>

   • This will scribble the date into the status file and rotate the logs
     
     

2. Edit /var/lib/logrotate/status and add the line manually:

   "/var/log/my_special.log" 2013-4-8

   • setting it to today's or a prior date. Next run should cause it to run.

Answer 2

According to the following Slicehost article:

Understanding logrotate on Ubuntu - part 2
http://articles.slicehost.com/2010/6/30/understanding-logrotate-on-ubuntu-part-2

... the /var/lib/logrotate/status file "stores information about when it last rotated each log file.". The logrotate manpage says that is called a "state file".

There's another discussion here in ServerFault that may also be useful:

How does logrotate exactly handle "daily"?

In that discussion, "MadHatter" says the following, regarding the "status" (state) file:

" Each file has one line, which is the date on which it was last rotated; if you run logrotate on such a date that a given file is due for rotation, given the number of days between current date and the date in the file (1 for daily, 7 for weekly, etc.), the file will be rotated. "

I hope this helps.

Answer 3

Try checking the logrotate output for the word "error". It seems logrotate skips some tasks (but not all tasks) when it encounters errors.

For example, under Debian/Ubuntu, you can run:

/usr/sbin/logrotate /etc/logrotate.conf --verbose --force |& grep -i '[^-_/.]error'

The regexp is to avoid listing files that contain the word "error". The ampersand is to also redirect stderr to grep (according to the Advanced Bash-Scripting Guide ) :

|& has been added to Bash 4 as an abbreviation for 2>&1 |

Answer 4

I had a similar issue on CentOS where my weekly log backups were not running. The problem ended up being someone removing the execute permissions on the /etc/cron.daily/0anacron file. Changed permissions back to 755 and it worked as intended.

Answer 5

If mysqladmin requires a user or password it will not read it from /root/.my.cnf configuration without modification.

Try piping your output to logger to see what is happening.

  postrotate
      # just if mysqld is really running
      if test -x /usr/bin/mysqladmin && \
         /usr/bin/mysqladmin ping &>/dev/null
      then
         env HOME=/root/ /usr/bin/mysqladmin flush-logs 2>&1 | logger
      else
         logger "mysqladmin ping failed so not rotating mysql logs"
      fi
  endscript

MySQL doesn't logs error to new file after rotating?