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

  • Do you have any kind of error ? Verify that "include /etc/logrotate.d" is not commented.
    – Torian
    Aug 17, 2011 at 12:29
  • 1
    How do you know it won't rotate your logs? Errors? Not happening after 30 days? Are these boxes up all the time? Is logrotate scheduled in cron? Aug 17, 2011 at 12:31
  • I can verify that "include /etc/logrotate.d" is in place in both systems. No errors except some interesting entry in syslog, like ...rsyslogd was HUPed... not sure about this means anything.
    – fabrik
    Aug 17, 2011 at 12:32
  • @EightBitTony These are servers so they're up and running continuously. Settings are more or less are the defaults (logrotate config wasn't modified by me), only the usual stuff installed. logrotate is included in cron.daily yet rotating won't happen.
    – fabrik
    Aug 17, 2011 at 12:34
  • @Fabrik please add logrotate -d /etc/logrotate.conf output to the question Aug 17, 2011 at 12:39

6 Answers 6


Check that your logrotate is being run by cron.


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


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 
  • This is totally looks like my config except the fact mine doesn't working :(
    – fabrik
    Aug 18, 2011 at 4:28
  • Is cron running check the output of ps -ef | grep cron| grep -v grep? Add an echo to the beginning of the /etc/cron.daily/logrotate echo "logrotate runing" >>/tmp/logrotate.out and see if it gets created.
    – user9517
    Aug 18, 2011 at 7:05
  • Looks like there's something went wrong with my crontab. cron is up and running but won't run the daily logrotate job. If i run /etc/cron.daily/logrotate manually it rotates my logs, /tmp/logrotate.out also written.
    – fabrik
    Aug 18, 2011 at 7:21
  • Don't forget the daily job won't run again till tomorrow!
    – user9517
    Aug 18, 2011 at 7:30
  • of course but yesterday i've modified /etc/cron.daily/logrotate so i've added a -f parameter to force rotating yet today morning my logs wasn't rotated.
    – fabrik
    Aug 18, 2011 at 7:33

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.

  • thanks, had this issue, too. Deleted all the 1.gz files and it finally resumed working. what a horrible piece of code. Jan 23, 2016 at 20:05

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:

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.


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


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).


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.

You must log in to answer this question.

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