Logrotate not working

Solution 1:

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)

Solution 2:

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/site.com/logs/

Solution 3:

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.

Solution 4:

Try running sudo logrotate -f --verbose /etc/logrotate.d/apache2 See what's written in console, and fix anything that is wrong.