Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am trying to get logrotate to work on my VPS to rotate my apache files weekly. Currently the contents of the apache2 config file is as such.

"/var/www/user/*.log"   {
        rotate 8
        create 640 root adm
                /etc/init.d/apache2 reload > /dev/null

I've left it for two weeks now and nothing has changed as far as I can tell. When I simulate it from the command line I get the following output.

user@geneva:/var/lib/logrotate$ /usr/sbin/logrotate -d /etc/logrotate.d/apache2
reading config file /etc/logrotate.d/apache2
reading config info for "/var/www/user/*.log" 

Handling 1 logs

rotating pattern: "/var/www/user/*.log"     weekly (8 rotations)
empty log files are not rotated, old logs are removed
considering log /var/www/user/
  log does not need rotating
considering log /var/www/user/
  log does not need rotating
not running postrotate script, since no logs were rotated

Any ideas as to what Iv'e configured wrong?

My status file is empty too :(

user@geneva:~$ cat /var/lib/logrotate/status
logrotate state -- version 2


I deleted the status file and did a force run of logrotate and now the logs look like they have been rotated and the status file looks more promising!

sudo rm /var/lib/logrotate/status

sudo /usr/sbin/logrotate -f /etc/logrotate.conf
share|improve this question

3 Answers 3

up vote 11 down vote accepted

I think that weekly means that logrotate wants to see at least a week old entry for your access.log file in order to rotate it.

Hence the problem seems to be that you are not storing the state entry to trigger the rotation.

Here is a stepped through example of the simple of case, of how logrotate decides to rotate a logfile
(these are fedora paths, Ubuntu, Centos etc may be different)

(I made a few request to http://localhost so there are some entries in access_log, otherwise logrotate never rotates...)

So I have set my logrotate for apache to weekly like so;

/var/log/httpd/*log {

and originally there is no entry in the /var/lib/logrotate.status file

# grep access_log /var/lib/logrotate.status
<- nothing

So logrotate does not rotate the access_log file;

 #  /usr/sbin/logrotate  -d /etc/logrotate.d/httpd 
considering log /var/log/httpd/access_log
  log does not need rotating

However if I run logrotate manually like so;

#  /usr/sbin/logrotate   /etc/logrotate.d/httpd 

there is now an entry in the state file for the httpd access_log;

 # grep access_log /var/lib/logrotate.status
 "/var/log/httpd/access_log" 2012-5-11

However apache is still not going to rotate the log, because the entry is only 0 days old (2012-5-11);

  #  /usr/sbin/logrotate  -d /etc/logrotate.d/httpd 
 considering log /var/log/httpd/access_log
   log does not need rotating

However if you edit the status file with vi vi /var/lib/logrotate.status so something like this to set the date to more than a week...;

 # grep access_log /var/lib/logrotate.status
 "/var/log/httpd/access_log" 2012-4-11    <---    more than a week ago..

Then logrotate now correctly rotates the file due to the date in the state file 2012-4-11 being more than a week ago from today 2012-5-11

 #  /usr/sbin/logrotate  -d /etc/logrotate.d/httpd
 considering log /var/log/httpd/access_log
 log needs rotating           <---    logrotate rotates the file.

(bear in mind that the -d causes a dry-run, hence is only useful for inspecting, you have to actually run the command without -d to make status entries or rotate files etc)

share|improve this answer
The log files did have entries way over a week old - It would appear that it is functioning now, however I guess I will find out a week from now... – Malachi May 11 '12 at 20:28
Sorry, I could have been more clear in the answer, but I think for a weekly rotate it needs an entry in the file /var/lib/logrotate.status with a date at least a week old. I updated the answer with an example... – Tom H May 11 '12 at 20:36
Thanks for such a clear explanation - I totally understand about the date side of things, it's just they don't rotate unless I manually call the command... It's as if CRON isn't calling log rotate? – Malachi May 24 '12 at 19:45
I'm relatively new to Linux administration... Inside /etc/cron.daily/logrotate/ there is: #!/bin/sh test -x /usr/sbin/logrotate || exit 0 – Malachi May 24 '12 at 19:59
log does not need rotating

This can be because you log files are empty.
This situation can happens because apache still write in a previous log file, which has been renamed without restarting apache. So access.log became access.log.1 and apache writes into it.

Or you have a problem with log's creation time:

ls -al --time=ctime /var/www/user/
share|improve this answer
You can comment out the notifempty line to deal with the 0 byte logs not rotating. Then you'll want to touch a new log file before each test so logrotate has something to rotate. – Banjer May 30 '14 at 14:25

I faced the similar issue except for none of these answers helped me. My log file was huge and old, my configuration was 100% ok and valid, removing the status file didn't help.

Turned out the the problem was in duplicate logrotate entries. When I run logrotate manually on my config file only like that:

logrotate -df /etc/logrotate.d/my_service_name

it didn't show any errors, it just said:

log does not need rotating

I still don't know why actually. But when I run a complete logrotate command like that:

logrotate -f /etc/logrotate.conf

I got the following line:

error: my_service_name:1 duplicate log entry for /var/log/nginx/my_service_name.access.log

It turned out that logrotate config file for my service contained the entries for rotating nginx access logs as well as the service logs itself. And that conflicted with the ngnix logrotate config, which has a rule for all nginx entries:

# grep nginx /etc/logrotate.d/*
/etc/logrotate.d/nginx:/var/log/nginx/*.log {

So the solution for my case is pretty simple: I just had to delete conflicting nginx logs rotation rule from my config.

I suppose logrotate started to abort processing file on rule conflicts only from one of the newest versions. I get this error with v.3.8.7 but under v.3.7.8 with the same conflicting configuration it writes out the same error but rotates fine. Although I couldn't find any record of that in the logrotate changelog.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.