logrotateが動いているか確認してから設定を変更する｜強制ローテートと圧縮の検証手順

logrotateの設定を変更したいと思ったとき、多くの運用者がまず設定ファイルを書き換えようとします。しかし実際には、現在の動作状態を先に把握しておくほうが、設定変更後のトラブルを防ぎやすくなります。設定ファイルを編集しても、そもそもlogrotateが動いていなければ変更は反映されません。また、ローテートが走っているように見えても、圧縮が機能していない、対象ファイルが誤っているといった問題が潜んでいることもあります。本記事では、動作確認・強制ローテート・圧縮の検証を順に行う、確実性の高い手順を解説します。

設定変更の前に動作確認が必要な理由

現場でよく起きるのは、設定ファイルを書き換えたつもりが別のファイルに上書きされていたケースや、/etc/logrotate.d/ に書いたルールが誤ったパスを参照していてローテートが一度も走っていなかったケースです。こうした問題は、事前に動作状態を確認しておけば早い段階で発見できます。

また、logrotateの実行方式はディストリビューションや構成によって異なります。systemdタイマー方式とcron方式が混在している環境も珍しくなく、設定を変えた後に「いつ反映されるか」を把握するためにも、実行方式の確認は欠かせない手順です。

状態を確認せずに設定を変更してしまうと、意図しない動作変更が生じたときに「設定変更が原因なのか、それとも以前から問題があったのか」の切り分けが難しくなります。変更前の状態を記録しておくことが、トラブルシュートのスタート地点になります。

logrotateの実行方式を把握する

logrotateはコマンド単体では動作せず、定期的に呼び出される仕組みが必要です。現在の主流な環境では、大きく2つの実行方式が使われています。

systemdタイマー方式（現行標準）

RHEL 8以降、Ubuntu 20.04以降、Debian 10以降など、近年リリースされた主要なディストリビューションでは、logrotateのトリガーにsystemdタイマーが使われています。タイマーが存在するかどうかは次のコマンドで確認できます。

systemctl list-timers --all | grep logrotate

logrotate.timer が active 状態であり、直近の実行時刻と次回の予定時刻が表示されれば、systemdタイマー方式で動いています。

cronによる実行方式（旧来・一部の構成）

一部のディストリビューションや、古い設定を引き継いだ環境では、/etc/cron.daily/logrotate というスクリプトがcronによって毎日実行される形をとっています。

ls /etc/cron.daily/ | grep logrotate

このファイルが存在し、実行権限がついていればcronから呼び出される形です。systemdタイマーとcronの両方が存在する環境では、どちらが実際に機能しているかを確認する必要があります。一般に、systemdタイマーが有効な場合はcronのスクリプトが実行されないよう制御されていますが、旧来のパッケージから引き継いだ構成では例外もあるため、現物での確認が重要です。

現在の動作状態を確認する

実行方式を把握したら、logrotateが実際に動いているかどうかをログと状態ファイルで確認します。

systemdの場合：タイマーとサービスのステータス

systemctl status logrotate.timer
systemctl status logrotate.service

logrotate.timer が active (waiting) と表示されていれば、タイマーは正常に動作しています。logrotate.service では直近の実行結果が確認でき、Succeeded と表示されていれば正常終了しています。エラーが出ている場合は、このステータス表示の中に原因のヒントが含まれていることが多いです。

journalctlによる実行履歴の確認

journalctl -u logrotate.service --since "7 days ago"

過去1週間の実行ログをまとめて確認できます。エラーが出ているセッションがあれば、その日時と内容を把握しておくことで、設定変更の影響範囲を事前に絞り込めます。

状態ファイルで最終実行日時を確認する

logrotateは実行のたびに状態ファイルを更新します。このファイルを読むと、各ログファイルに対していつローテートが実行されたかが一覧できます。

cat /var/lib/logrotate/logrotate.status

ディストリビューションによっては /var/lib/logrotate.status（サブディレクトリなし）にあることもあるため、存在しない場合は両方のパスを確認してください。日付が古いまま止まっているエントリがあれば、そのログファイルに対するルールが正しく機能していない可能性があります。

デバッグモードで設定の妥当性を検証する

設定ファイルを変更する前後には、デバッグモードを使って実際にローテートが行われるかどうかをシミュレートできます。デバッグモードはログファイルに対して何も変更を加えないため、本番環境で安全に実行できます。

logrotate -d /etc/logrotate.conf

-d オプション（--debug）を指定すると、処理の内容が標準エラー出力に表示されますが、実際のファイル操作は行われません。出力の中で注目すべきは「considering log」から始まる行と「rotating pattern」の内容です。ここにエラーが含まれている場合、設定の構文や対象パスに問題があります。

特定の設定ファイルだけを確認したい場合は、個別のファイルを引数に指定することもできます。

logrotate -d /etc/logrotate.d/nginx

出力の末尾に「not rotating empty log」と表示された場合、対象のログファイルが空であるためローテートがスキップされています。これは正常な動作ですが、ifempty オプションを設定すると空のファイルでもローテートするよう動作を変更できます。また、「log does not need rotating」と表示される場合は、設定した日数やサイズの条件をまだ満たしていないことを意味します。強制実行（-f）を使えばこの条件を無視してローテートできます。

強制ローテートと圧縮の確認手順

デバッグモードで問題がないことを確認したら、実際に強制ローテートを実行して動作を検証します。特に圧縮設定を変更した場合は、強制実行による確認が欠かせません。

強制ローテートの実行と結果確認

-f（--force）オプションを付けると、ローテート条件（サイズ・日数）に関わらず強制的にローテートが実行されます。rootまたはsudo権限が必要です。

logrotate -f /etc/logrotate.d/nginx

実行後、対象のログディレクトリを確認します。

ls -la /var/log/nginx/

ローテートが成功していれば、access.log.1 や access.log.1.gz（圧縮が有効な場合）といったファイルが生成されているはずです。元のログファイルは空のまま残り、新規のアクセスログの書き込み先となります。postrotate スクリプトで対象のサービスにシグナルを送る設定をしている場合は、サービスが正常にログファイルを再オープンしているかも合わせて確認しておくと安全です。

圧縮ファイルの内容を検証する

設定ファイルに compress が指定されている場合、ローテートされたログは .gz 形式で圧縮されます。圧縮が正しく行われているかどうかは次のコマンドで確認できます。

file /var/log/nginx/access.log.1.gz
zcat /var/log/nginx/access.log.1.gz | head -n 5

file コマンドが gzip compressed data と返せば、圧縮形式が正しいことが確認できます。zcat で内容を展開して読めることも確認しておくと、バックアップとして実際に参照できる状態にあることが保証されます。

なお、compress と delaycompress を組み合わせている場合、直前のローテートファイル（.log.1）は圧縮されず、次のローテート時に圧縮される仕様です。この動作を理解していないと「圧縮されていない」と誤認して設定を変えてしまうことがあります。-d オプションの出力でどちらの設定が適用されているかを確認してから -f を実行するのが確実な手順です。

設定変更後の検証フローと2026年現行環境での注意点

設定変更の手順としては、まず -d でシミュレーション、次に -f で強制実行と結果確認、最後に次回の定期実行後にも状態ファイルを再確認するという3段階を踏むのが確実です。設定を変更する前には変更前のファイルをコピーしておきます。

cp /etc/logrotate.d/nginx /etc/logrotate.d/nginx.bak

問題が起きた場合は元のファイルに戻し、再度 -d で確認してから修正を加えます。logrotateは設定ファイルにエラーがあっても処理を継続することがあるため、エラーが出ているからといって他のルールが全部止まっているわけではありませんが、問題のある設定は早期に修正するほうが安全です。

2026年時点での主要ディストリビューションにおける注意事項として、以下の点が挙げられます。

• RHEL 9・AlmaLinux 9・Rocky Linux 9では、logrotateのsystemdタイマーがデフォルトで有効になっています。/etc/cron.daily/logrotate が残存していても、systemdタイマーが優先されます。
• Ubuntu 24.04（Noble Numbat）ではsystemdタイマーが標準となっており、cron.daily 経由の実行は廃止されています。
• Debian 12（Bookworm）以降も同様にsystemdタイマー方式が主流です。
• コンテナ環境（DockerやPodmanの最小イメージ）ではsystemdが動いていないため、ホスト側のcronかコンテナ内での別途スケジュール実装が必要になります。ボリュームマウントしたログに対してホスト側のlogrotateを適用する場合は、copytruncate オプションが有効なケースもあります。
• RHEL 9以降では --debug オプションの出力形式が若干変わっており、以前は標準エラー出力のみだったものが、設定によってはsystemdのジャーナルにも記録されます。

logrotateはシンプルなツールですが、実行方式の違いや delaycompress のような設定の組み合わせによって、期待と異なる動作をすることがあります。設定を変更する際には必ず事前に動作状態を確認し、デバッグモードと強制実行で検証してから本番の定期実行に委ねるというフローを習慣にすることで、予期しないディスク満杯やログ欠損を防ぐことができます。