Apache2 and logrotate: delaycompress needed?

Question

I am currently looking at the file size of my Apache logs as they became huge. In my logrotate conf, I have delaycompress enabled. Does Apache really need this (as the logrotate documentation says that some programs still write in the old file) or is it safe to disable delaycompress?

Here is my logrotate config:

/var/log/apache2/*.log {
    weekly
    missingok
    rotate 26 
    compress
    delaycompress
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
            if [ -f /var/run/apache2.pid ]; then
                    /etc/init.d/apache2 restart > /dev/null
            fi
    endscript
}

Best regards,

Jonas

Answer 1

If you're doing an Apache restart (or even 'graceful') it will close open file handles and open them again. You shouldn't need delaycompress because the file will have been closed and re-opened as part of your postrotate restart.

rotate access_log -> access_log.1 (rename action, no INDOE change)
apache still writing to access_log.1 (same open FD on same INODE)
apache restart (close FD, release INODE writing)
apache writing to access_log (new FD to a new INODE)

A restart is kind of a bad idea - what if the config file accidentally changed and is no longer valid? Your apache won't start back up. Instead send a HUP to the parent process which tells it to close/re-open file handles.

postrotate
  /bin/kill -HUP `cat /var/run/apache2.pid 2>/dev/null` 2>/dev/null || true
endscript

cat will fail if the PID is missing (or empty, or invalid) causing kill to also fail so you don't need the if..then block around it.

Answer 2

Hrm, in this case, probably, as Apache keeps the logs open.

One thing you can try is the rotatelogs script. It's part of the apache2-utils package, at least here on my Ubuntu workstation. Another approach would be to rotate them daily instead of weekly, so you're buffering less before compression.