logrotate won't rotate my logs automatically

Question

I have two different (i386 v AMD) Debian boxes and have the same problem. logrotate won't rotate my logs automatically. It works fine when i force it manually like

/usr/sbin/logrotate -f /etc/logrotate.conf

but it's not okay for me.

Settings wasn't modified (at least i didn't modified them), the AMD box is a fresh install yet won't do it's job.

If you have noticed a similar problem, please help me.

Update (some server output):

logrotate -d http://pastebin.com/e6AshtGq

ls -l /var/log http://pastebin.com/Y2A4Li59

cat /etc/logrotate.conf http://pastebin.com/1h7Uwctr

ls -l /etc/logrotate.d http://pastebin.com/NvUAeszM

Answer 1

Check that your logrotate is being run by cron.

Edit:

From the comment discussion - it appears that cron is not working correctly. I had a cronjob in my crontab without user but this only come to light when I restarted the cron daemon

My ubuntu and centos systems have an /etc/cron.daily/logrotate file the contents of which are

#!/bin/sh

test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate /etc/logrotate.conf

My /etc/crontab has the following line to run the daily jobs

25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily 

Answer 2

I had a similar issue but crontab was working and for some of the log directories logrotate worked but for some it didn't. When I tried to run the logrotate manually, I got some error messages.

user@server:/var/log/apache2$ sudo /usr/sbin/logrotate -f /etc/logrotate.conf
error: error creating output file /var/log/apache2/access.log.1.gz: File exists
error: error creating output file /var/log/apache2/error.log.1.gz: File exists
...

All of the *.1.gz files had a size of 0. I manually deleted all of the files mentioned in the error message, ran sudo /usr/sbin/logrotate -f /etc/logrotate.conf again and it worked.

I just though I should share this alternate solution here as well, since this was the first search result that came up for me when I was searching for the problem but the suggested solution didn't work for me. Maybe this helps others as well who are in the same situation as I am.

Answer 3

I know I know. 5 year-old thread.

Just thought if it still comes up quite high in the searches, I'll contribute and give my solution to the problem I encountered. My logrotate jobs were not handled automatically on one of my servers. Forcing the rotation worked fine. I came up with a solution after I ran the daily rotation command by hand:

( cd / && run-parts --report /etc/cron.daily )

Then I saw the error that stopped logrorate jobs from firing:

/etc/cron.daily/logrotate:
error: iptraf-ng:2 duplicate log entry for /var/log/iptraf/*.log

Yes, as simple as that. I had two files defining the same logs to rotate (iptraf and iptraf-ng). Just removing one of the conflicting logrotate definitions for iptraf did the trick.

rm /etc/logrotate.d/iptraf

Another problem might be a botched /etc/crontab file. Meaning double or triple check the syntax on that file as it doesn't provide any output I could find if syntax is wrong. Quietly exits after failed syntax validation.

Hope this saves someone some time.

Answer 4

OK I had a similar issue.

"logs aren't being rotated?" but running logrotate manually (or running the /etc/cron.daily and it rotates them just fine.

So it appears that cron just "isn't running" daily. Odd. So I looked in the logfile where cron outputs its data and saw " Authentication token is no longer valid; new one required" for fix to that particular issue, see here

Answer 5

I have seen this happen often over time as services change, and the options used in logrotate have been redacted, causing logrotate to fail each day.

To give you an idea, the last fix involved the notifyempty option in the apache logrotate file not being valid anymore, in turn causing logrotate to stop all together.

While this has been covered to a point, I would like to share the process I go through when tracking down these issues:

1. start by running #/usr/sbin/logrotate -f /etc/logrotate.conf to look for any errors (e.g. postfix:3 'missingok'.)
   The file and line number it is referring to is the file in the logrotate.d folder.
2. Edit the file in question: # vi /etc/logrotate.d/postfix, and remove the option causing the issue, and save the file.
3. Repeat the first step to see if rotates work, or if there are other issues.

There are times when the first step simply does output anything, but you know there is an issue. Since this whole thing started because the log files for a service are were not being rotated, you can watch the logrotate process looking for that specific service to see what is stopping it from rotating. To do this, add the verbose tag to your logrotate command, and watch to see what happens in that folder (if anything).

Answer 6

Check for conflicting logrotation configuration parameters !!

I was struggling with this issue and I finally read some documentation on logrotate very closely, I found some useful documentation here.

I had specified both a Size parameter and a Rotation Interval parameter, when in fact I wanted neither. I wanted my rotations to occur exactly when they were scheduled in cron.

1. Size parameter will override any rotation interval. So my logs needed to exceed this parameter before they would ever be rotated. (I can see how this would be useful when you were most worried about disk usage. But that is not how I wanted to use it.)
2. Rotation Interval will check when the last rotation occurred and make sure the next rotation is delayed by the specified amount. But, I am unclear on how you control when that time occurs, it is based off the last time a rotate happened.

So, get rid of the Rotation Interval and Size parameter. Then you will get a rotation every time logrotate is called without having to force it.

EDIT: OK even this does not entirely work! If the log file is below a certain threshold, the logs will not rotate. So when I ran a cron job that rotated every 2 minutes, it did not rotate the logs.

You can see detailed debug information if you run logrotate -d. This provides some very useful debug info.