When logrotate fails to automatically rotate Apache logs despite proper configuration, the issue typically stems from either the status file tracking or the rotation criteria not being met. The initial configuration appears correct:

"/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
}

The empty status file (/var/lib/logrotate/status) indicates logrotate hasn't properly tracked previous rotations. This file normally contains timestamps of last rotations for each log file.

Using the -d debug flag reveals important information:

/usr/sbin/logrotate -d /etc/logrotate.d/apache2

When the output shows "log does not need rotating," it typically means either:

• The log hasn't reached the rotation interval (weekly)
• The file size is below any size threshold (if specified)
• The status file wasn't properly updated

The working solution involves two steps:

# Remove the status file
sudo rm /var/lib/logrotate/status

# Force a rotation run
sudo /usr/sbin/logrotate -f /etc/logrotate.conf

For more reliable rotation, consider adding these parameters:

size 100M
dateext
dateformat -%Y%m%d

This ensures rotation either weekly or when logs reach 100MB, whichever comes first, with date-based naming.

Verify logrotate is actually running via cron:

cat /etc/cron.daily/logrotate

Or check systemd timer on newer systems:

systemctl list-timers | grep logrotate

After successful rotation, check:

ls -lh /var/www/user/site.com/logs/
cat /var/lib/logrotate/status

The status file should now contain entries like:

"/var/www/user/site.com/logs/access.log" 2024-2-20-12:0:0

When setting up weekly log rotation for Apache2 access/error logs, the configuration appeared correct but wasn't executing as expected. The key indicators were:

# Diagnostic command output
$ /usr/sbin/logrotate -d /etc/logrotate.d/apache2
...
considering log /var/www/user/site.com/logs/access.log
  log does not need rotating

Logrotate maintains state information in /var/lib/logrotate/status. In this case, the file was essentially empty:

$ cat /var/lib/logrotate/status
logrotate state -- version 2

This prevented logrotate from properly tracking when rotations should occur, causing it to consistently report "log does not need rotating" even when the weekly rotation period had passed.

The fix involved two steps:

# Remove the corrupted status file
sudo rm /var/lib/logrotate/status

# Force a rotation run
sudo /usr/sbin/logrotate -f /etc/logrotate.conf

Here's an improved version of the configuration with additional best practices:

"/var/www/user/site.com/logs/*.log" {
    weekly
    missingok
    rotate 8
    compress
    delaycompress
    notifempty
    create 640 root adm
    sharedscripts
    dateext
    dateformat .%Y-%m-%d
    postrotate
        # More reliable Apache restart methods
        if [ -f /var/run/apache2.pid ]; then
            /usr/sbin/apache2ctl graceful > /dev/null 2>&1 || true
        fi
    endscript
}

To ensure ongoing proper operation:

# Check rotation status
sudo logrotate --debug /etc/logrotate.conf

# Verify status file contents
sudo cat /var/lib/logrotate/status

# Add daily cron check (in /etc/cron.daily/logrotate)
#!/bin/sh
/usr/sbin/logrotate /etc/logrotate.conf
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
    /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit 0