logrotate.conf says rotate logs weekly, but my logs haven't rotated for 5 weeks. What could be stopping my logs from rotating?


# rotate log files weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones

size 100M

# uncomment this if you want your log files compressed

# packages drop log rotation information into this directory
include /etc/logrotate.d

/var/log/wtmp {
    create 0664 root utmp
    rotate 1

/var/log/btmp {
    create 0660 root utmp
    rotate 1

There is no state file

sudo logrotate -f /etc/logrotate.conf produces

error: error creating output file /var/log/syslog.1.gz: File exists
error: error creating output file /var/log/daemon.log.1.gz: File exists
error: error creating output file /var/log/kern.log.1.gz: File exists
error: error creating output file /var/log/auth.log.1.gz: File exists
error: error creating output file /var/log/user.log.1.gz: File exists
error: error creating output file /var/log/debug.1.gz: File exists
error: error creating output file /var/log/messages.1.gz: File exists

After deleting these files the logrotate rotated the logs, so I guess that solved my problem, thanks, though I can't think why logrotate couldn't handle it

  • That is a serious red flag, if you are running a server. be cautious, could you have a breech? – j0h Aug 5 '14 at 1:35
  • @jOh It is an internal server, behind a router with no external access – David Sykes Aug 5 '14 at 3:35
  1. Show us your logrotate.conf.
  2. Delete your state file /var/lib/logrotate.status and
  3. do logrotate -f /etc/logrotate.conf as root. Post back any error messages.
  4. You are running logrotate as a cron job? As root?
  • Logrotate is in the daily cron list, and cron is running, but I can't find any entries or errors in the logs – David Sykes Aug 5 '14 at 3:34
  • do $sudo dmesg -c then sudo logrotate -f then sudo dmesg the kernel ring buffer should show you what is happening. – j0h Aug 5 '14 at 5:22

I know I'm a little late to the game here, but since I found a reason for this not working for me, I wanted to help others:

This happened to me too, and I discovered a resolution yesterday.

Check to see if any of the compressed files (particularly all the *.1.gz fiels) have 0 bytes?

Technically this file exists, but the script sees it as empty, and therefore ignores it. Then tries to create this file - but can't as you can see above.

Delete the empty compressed files. Then go to /var/lib/logrotate.status and edit the dates for each of these files, so that logrotate thinks it is more than a week since it checked the files. I would recommend just changing the month back one.

Then run logrotate again and the script should run correctly.

  • You could also add minsize 1k to the top of /etc/logrotate.conf so that this doesn't happen -- see man logrotate. – goldilocks Jun 26 '15 at 10:13
  • Thanks, this worked for me. Shouldn't the minsize 1k be added to the stock logrotate.conf file, then? – Pierre-Antoine Aug 30 '16 at 13:23

My jessie systems had /etc/logrotate.conf installed belonging to pi and with permissions of 664 so logrotate refused to process it. Fixed with:

/bin/chown root.root /etc/logrotate.conf /bin/chmod 600 /etc/logrotate.conf /usr/sbin/logrotate -v /etc/logrotate.conf


Really late to the party, on this one... but this happened to me because I had a bunch of rotated logs (*.[1-9].gz) files, and then /etc/logrotate.d/rsyslog with a "delaycompress" directive. I'm assuming that I either had updated it to that, at some point, or that a later revision "fixed" that problem.

So, essentially none of the *.1.gz should have actually existed, and it was confusing logrotate. Removing the files (many of them 0-sized) and re-running logrotate, manually, fixed the problem.

Your Answer

