Apache2とlogrotate：delaycompressが必要ですか？

現在、Apacheログが巨大になったときのファイルサイズを調べています。私のlogrotate構成では、delaycompress有効にしました。Apacheは本当にこれを必要とするのですか（logrotateのドキュメントでは、一部のプログラムがまだ古いファイルに書き込んでいると記載されています）、それとも無効にしても安全delaycompressですか？

これが私のlogrotate設定です：

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

Apacheを再起動している場合（または「グレースフル」であっても）、開いているファイルハンドルが閉じられ、再度開かれます。ローテーション後の再起動の一部としてファイルが閉じられ、再度開かれるため、delaycompressは必要ありません。

rotate access_log -> access_log.1 (rename action, no INODE 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)

再起動は悪い考えです。構成ファイルが誤って変更されて無効になった場合はどうなりますか？Apacheがバックアップを開始しません。代わりに、親プロセスにHUPを送信し、ファイルハンドルを閉じる/再度開くように指示します。

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

PIDが欠落している（または空である、または無効である）場合、catは失敗し、killも失敗するため、そのif..then周りのブロックは必要ありません。

Hrm、この場合、おそらく、Apacheはログを開いたままにします。

試すことができる1つのことはrotatelogsスクリプトです。これはapache2-utilsパッケージの一部であり、少なくとも私のUbuntuワークステーションではここにあります。もう1つのアプローチは、毎週ではなく毎日ローテーションすることです。これにより、圧縮前のバッファリングが少なくなります。