Logrotate not working

Question

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/site.com/logs/*.log"   {
        weekly
        missingok
        rotate 8
        compress
        delaycompress
        notifempty
        create 640 root adm
        sharedscripts
        postrotate
                /etc/init.d/apache2 reload > /dev/null
        endscript
}

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

Handling 1 logs

rotating pattern: "/var/www/user/site.com/logs/*.log"     weekly (8 rotations)
empty log files are not rotated, old logs are removed
considering log /var/www/user/site.com/logs/access.log
  log does not need rotating
considering log /var/www/user/site.com/logs/error.log
  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

Update

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

Tom · Accepted Answer · 2012-05-11T21:06:08.970

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 {
        weekly
...
}

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)

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, 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
Thank you for the -d is dry-run. The logrotate man page is confusing when it says: -d, --debug ... Turns on debug mode and implies -v. This de-emphasizes the more important side-effect of not actually running. — arielf, Feb 09 '20 at 22:53

score 7 · Answer 2 · answered May 10 '12 at 21:36

7

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/

answered May 10 '12 at 21:36

Gregory MOUSSAT

1,761

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

score 7 · Answer 3 · answered Jan 12 '15 at 11:28

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.

you seem to be right about the most recent versions. I also had duplicate entries; but when running logrotate manually; it worked just fine. At night return value 0; but it hadn't run correctly... — Chris Maes, Sep 22 '16 at 09:45

score 2 · Answer 4 · answered Feb 16 '16 at 02:58

2

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

answered Feb 16 '16 at 02:58

Aminah Nuraini

1,079

score 0 · Answer 5 · answered May 01 '17 at 09:20

I had a Debian 7 machine which, following a system update, did not rotate mail logs anymore. All other logs but mail ones were correctly rotated. I discovered that mail logs had grown several gigabytes. I always managed log rotation via Webmin. Then, running logrotate -d /etc/logrotate.conf I saw the following message:

Ignoring rsyslog.dpkg-old, because of .dpkg-old ending

It came out that my mail rotation entries were listed in /etc/logrotate.d/rsyslog.dpkg-old, which was ignored! Renaming the file fixed the log file rotation :-)

Logrotate not working

5 Answers5

Linked