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

/var/log/mysql/mysql-slow.log {
    rotate 3
    create 660 mysql adm
    if test -x /usr/bin/mysqladmin && \
       /usr/bin/mysqladmin  ping &>/dev/null
       /usr/bin/mysqladmin  flush-logs


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
       /usr/bin/mysqladmin flush-logs
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?
  • So it does work when executed by hand? Is crond running?
    – Kyle Smith
    Commented Mar 29, 2012 at 19:47
  • yes it works, if you mean logrotate -f mysql_slow_query. And crond is running.
    – Carmen
    Commented Mar 29, 2012 at 19:50
  • Are you sure there isn't another config already that is supposed to handle that log file? Perhaps mysql-server? Run grep '/var/log/mysql' /etc/logrotate.d/*.
    – Zoredache
    Commented Mar 29, 2012 at 19:57
  • I ran that command and only my config show up as doing something in /var/log/mysql
    – Carmen
    Commented Mar 29, 2012 at 20:02
  • At what time of the day do the daily cron jobs run in your Ubuntu setup? You may find that information in the /etc/crontab file, in the line that ends with /etc/cron.daily ). Maybe you created the logrotate config after the cron daily jobs for that day had already run?
    – ricmarques
    Commented Mar 29, 2012 at 21:33

6 Answers 6


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.
  • 1
    Works like a champ!
    – Seth
    Commented Jan 2, 2015 at 19:47
  • 7
    Actually it does rotate the logs when using -f (at least on my RH derivative).
    – bufh
    Commented Jan 12, 2015 at 14:50
  • 17
    -f for Force Rotation, -d for Debug, also debug implies dry run so no changes will actually be made while -d is on. Commented Feb 22, 2016 at 23:32
  • 4
    -d implying dry run is a tricky one. No changes were being made, and had me scratching my head until I realized this fact. Commented Jan 3, 2019 at 22:56

According to the following Slicehost article:

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.


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.

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

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

  • On Debian installed db servers you might want to make sure you have valid credentials in /etc/mysql/debian.cnf as the default logrotate script that comes with the package by default will try to use the debian-sys-maint user as a fallback.
    – dom
    Commented Jul 30, 2021 at 11:40

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.


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 |


In my case (Ubuntu 20.04, logrotate 3.11.0) forcing logrotate to run (using -f) helped finding the cause of the thing not working (in spite of messages in syslog that confusingly appeared to show otherwise). Forcing the run prompted the error:

error: skipping ... because parent directory has insecure permissions

Adding a line noting the rightful owners of the parent directory:

su somegroup someuser

in my /etc/logrotate.d/ config file solved the problem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .