So I was getting all in a huff because logrotate wasn't rotating my log files (CentOS 5.2, but not a problem specific to that). It was really getting to me, as the config was EXACTLY the same as other servers (same OS, same versions of logrotate, even the same versions of crond running logrotate). I was testing by running "logrotate -d /etc/logrotate.conf" which reported that none of my logfiles needed to be rotated. The logfiles in question were over 2 weeks old and configured to rotate weekly, but still logrotate indicated they didn't need to be rotated. If I changed the config to daily instead of weekly, it correctly reported that they needed to be rotated.

Finally reading through the man page I noticed the -s, --state <statefile> flag, which I never really paid attention to (or knew about). Well, part of my investigation was trying to figure out how the heck logrotate determines when the log file was created. Turns out that it uses this state file to keep track of the last time logrotate rotated files, and thus when the files need to be rotated again.

That made the failure apparent -- I had only installed logrotate about 4 days ago, so on it's first run it wrote to the state file that the log files were "created" on that date. Since it only saw them as 4 days old, it determined they didn't need to be rotated. I confirmed that by editing the state file by hand to set the date back, and running logrotate with the -d flag again. Worked like a charm.

Long story short, after a fresh install and first run of logrotate it will take a full week to rotate weekly files, a month to rotate mothly files, etc. This can be corrected by editing the state file (/var/lib/logrotate.status by default) by hand.