問題発生時のトラブル解決ガイド

logrotateでログがローテーションされない原因と確認手順

設定したログが切り替わらない場合に、logrotateが設定を読んでいるか、条件を満たしているか、処理中に失敗したかを順に確認するページです。

このページの目的

ローテーションされない理由を、設定未読込み、対象外判定、権限・スクリプト失敗の3段階に分けます。最終的なゴールは、logrotate -dの判定理由を読み、修正すべき設定を特定することです。

最初に logrotate -d で設定の読込みと判定理由を確認します。強制実行から始めず、対象ログ、条件、状態ファイル、権限の順に確認します。

このページの対象：このページは「ログファイル自体が切り替わらない」場合が対象です。ローテーションは成功したのにアプリが新しいログへ書かない場合は、logrotate後にログを書かないガイドを確認してください。

設定を貼り付けて、対象パス、世代数、圧縮、create、copytruncate、postrotateなどの注意点を確認できます。

強制実行する前に、デバッグ出力を次の3つに分けて読みます。

sudo logrotate -d /etc/logrotate.conf

表示された文言は原因そのものではなく、確認範囲を絞る手掛かりです。「考えられる原因」と「最初の確認方法」を対応させて確認します。

エラー・症状	考えられる原因	最初の確認方法
`error: bad rotation count / unknown option`	設定値の形式誤り、または未対応・誤記したディレクティブ	logrotate -d の該当行と対象設定ファイルを確認
`error: skipping "..." because parent directory has insecure permissions`	親ディレクトリが第三者書込み可能で、su指定もない	親ディレクトリの所有者・権限とsu指定を確認
`error: stat of ... failed: No such file or directory`	対象ログのパス誤り、またはログファイルがまだ存在しない	ls -l とlogrotate設定内の対象パスを照合
`log does not need rotating`	期間・サイズ条件が未到達、または状態ファイル上で実行時期前	-d出力の判定理由とstatusファイルを確認
`error running shared postrotate script`	postrotate内のコマンドが失敗し、非0で終了した	postrotateのコマンドを単体実行し終了コードを確認
`duplicate log entry for ...`	同じログパスが複数の設定ブロックで指定されている	/etc/logrotate.conf とinclude先を検索して重複を確認

設定が読み込まれているか確認する
grep -n "include" /etc/logrotate.conf ls -l /etc/logrotate.d/
対象ファイルがinclude先にあり、ファイル名や権限が実装・ディストリビューションの要件を満たすか確認します。
対象ログと条件を確認する
ls -lh /var/log/example/app.log sudo logrotate -d /etc/logrotate.conf
daily、size、minsize、notifemptyなどの条件で対象外になっていないか確認します。
状態ファイルを確認する
sudo grep -F '/var/log/example/app.log' /var/lib/logrotate/logrotate.status 2>/dev/null || true
状態ファイルの場所は環境で異なります。前回ローテーション時刻を確認します。
権限と所有者を確認する
namei -l /var/log/example/app.log ls -ld /var/log/example /var/log/example/app.log
logrotateの実行主体と、su、createの指定が整合しているか確認します。
postrotateを単独確認する
systemctl reload example.service systemctl status example.service --no-pager
設定に書いた再読込処理が対象アプリで本当に有効か、単独で確認します。

デバッグ結果	主な対応
log does not need rotating	期間・サイズ・状態ファイルを確認します。
error opening ... Permission denied	親ディレクトリ、ファイル権限、`su`を確認します。
ローテーション済みだがアプリが旧ファイルへ書く	postrotateで再オープン通知するか、アプリ仕様に応じて方式を見直します。
新しいログへ書けない	`create`のモード・所有者・グループを確認します。

影響を理解したうえで、個別設定と専用の一時状態ファイルを使って検証すると、本番の状態ファイルを汚しにくくなります。

sudo logrotate -d /etc/logrotate.d/example sudo logrotate -v -s /tmp/logrotate-test.status /etc/logrotate.d/example

-fによる強制実行は、ログの切替、圧縮、削除、postrotateを実行する可能性があります。本番ログではバックアップと影響確認を先に行ってください。