When examining your logrotate configuration for Apache (/etc/logrotate.d/apache2), several key directives are in place:

/var/log/apache2/*.log {
    weekly
    missingok
    rotate 2
    compress
    delaycompress
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
        /etc/init.d/apache2 reload > /dev/null
    endscript
}

The verbose output reveals the core issue:

rotating pattern: /var/log/apache2/*.log  weekly (2 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/apache2/access.log
  log does not need rotating

• Rotation criteria not met: The weekly interval hasn't triggered because:
  • Not enough time has passed since last rotation (check timestamps with ls -lta /var/log/apache2/)
  • Log files haven't reached size thresholds
• Compression timing: delaycompress keeps one uncompressed version
• Permission issues: Verify logrotate has write access to the directory

To test the rotation mechanism immediately:

logrotate --force --verbose /etc/logrotate.d/apache2

Consider these enhancements to your configuration:

/var/log/apache2/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 640 root adm
    sharedscripts
    dateext
    dateformat .%Y-%m-%d
    extension .log
    postrotate
        /usr/bin/systemctl reload apache2 > /dev/null
    endscript
}

1. Check current rotation status:

   ls -lth /var/log/apache2/

2. Verify logrotate execution:

   grep logrotate /var/log/syslog

3. Test cron job execution:

   run-parts --test /etc/cron.daily

When examining an Apache server's log directory, I noticed something peculiar - despite having rotate 2 in my logrotate configuration, dozens of compressed log files remained:

# ls /var/log/apache2/ | wc -l
85

Here's the relevant logrotate configuration for Apache:

/var/log/apache2/*.log {
    weekly
    missingok
    rotate 2
    compress
    delaycompress
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
        /etc/init.d/apache2 reload > /dev/null
    endscript
}

The verbose output from logrotate shows it's considering the logs but deciding not to rotate them:

rotating pattern: /var/log/apache2/*.log  weekly (2 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/apache2/access.log
  log does not need rotating

Several factors could cause this behavior:

• The weekly interval hasn't been reached since last rotation
• Files might not meet size thresholds for rotation
• Permission issues preventing logrotate from removing files
• Custom cron job settings interfering with logrotate

To test the rotation behavior manually:

# logrotate --force --verbose /etc/logrotate.d/apache2

If files still aren't removed after forced rotation, check:

# ls -la /var/log/apache2/
# stat /var/log/apache2/access.log

Consider modifying the configuration to use size-based rotation instead of time-based:

/var/log/apache2/*.log {
    size 100M
    missingok
    rotate 2
    compress
    delaycompress
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
        systemctl reload apache2 > /dev/null
    endscript
}

Check when logrotate last ran and its configuration:

# cat /etc/cron.daily/logrotate
# ls -l /etc/logrotate.d/