36

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?
Improve this question
8
  • So it does work when executed by hand? Is crond running? Commented Mar 29, 2012 at 19:47
  • yes it works, if you mean logrotate -f mysql_slow_query. And crond is running. 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/*. Commented Mar 29, 2012 at 19:57
  • I ran that command and only my config show up as doing something in /var/log/mysql 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? Commented Mar 29, 2012 at 21:33

6 Answers 6

Reset to default
72

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.
Improve this answer
4
  • 1
    Works like a champ! Commented Jan 2, 2015 at 19:47
  • 7
    Actually it does rotate the logs when using -f (at least on my RH derivative). 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
  • 5
    -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
7

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.

Improve this answer
1

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?

Improve this answer
1
  • 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. Commented Jul 30, 2021 at 11:40
1

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.

Improve this answer
1

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 |

Improve this answer
0

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.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.