logrotateでログがローテーションされない原因と確認手順
このページの目的
ローテーションされない理由を、設定未読込み、対象外判定、権限・スクリプト失敗の3段階に分けます。最終的なゴールは、logrotate -dの判定理由を読み、修正すべき設定を特定することです。
最初にやること
最初に logrotate -d で設定の読込みと判定理由を確認します。強制実行から始めず、対象ログ、条件、状態ファイル、権限の順に確認します。
ローテーションされないときの最短チェック
sudo logrotate -d /etc/logrotate.conf-d はログやstateを変更せず、設定読込と判定理由を確認する入口です。
systemd環境では systemctl status logrotate.timer と systemctl status logrotate.service を確認。環境によってcron等で実行されます。
stateファイルの場所を確認し、対象ログの前回ローテーション時刻と条件を照合します。
-f は実際にローテーションを実行し得ます。まず -d、必要なら検証環境や専用stateで -v を使います。
logrotate -d の判定結果を別々に確認すると、原因を早く絞れます。logrotate設定を実行前に確認
設定を貼り付けて、対象パス、世代数、圧縮、create、copytruncate、postrotateなどの注意点を確認できます。
最初に判定理由を確認する
強制実行する前に、デバッグ出力を次の3つに分けて読みます。
- 設定を読めていない：include先、ファイル名、構文を確認
- 対象だが条件未達：前回実行時刻、サイズ、期間、空ファイル条件を確認
- 処理を開始したが失敗：権限、
su、postrotateを確認
よくある表示・症状から原因を絞る
表示された文言は原因そのものではなく、確認範囲を絞る手掛かりです。「考えられる原因」と「最初の確認方法」を対応させて確認します。
| エラー・症状 | 考えられる原因 | 最初の確認方法 |
|---|---|---|
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先にあり、ファイル名や権限が実装・ディストリビューションの要件を満たすか確認します。
logrotate自体が定期実行されているか確認する
systemctl status logrotate.timer --no-pager 2>/dev/null || true systemctl list-timers --all | grep -i logrotate || true systemctl status logrotate.service --no-pager 2>/dev/null || truesystemdを使う環境では
logrotate.timerから起動される構成があります。別のcronやジョブ管理で起動する環境もあるため、実際の実行方式を確認します。対象ログと条件を確認する
ls -lh /var/log/example/app.log sudo logrotate -d /etc/logrotate.confdaily、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.loglogrotateの実行主体と、
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のモード・所有者・グループを確認します。 |
| 設定は正しいが定期実行されていない | logrotate.timer / cron / ジョブ管理の実行状態とログを確認します。 |
この症状で多い原因
- 設定ファイルがinclude対象外、または無視される名前になっている
- 期間・サイズ条件をまだ満たしていない
notifemptyにより空ログが対象外になっているsuやディレクトリ権限が合っていない- アプリがログファイルを開き直さず、旧ファイルへ書き続けている
- postrotateのコマンドやサービス名が誤っている
方式を変える前に、通常ローテーション・postrotateとの違いとリスクを確認します。
copytruncateとpostrotateを比較 →ローテーション自体は成功している場合は別の切り分けです。
書込み停止の原因を確認 →個別原因の調査と並行して設定の注意点を確認できます。
設定をレビュー →修正後の確認と再発防止
影響を理解したうえで、個別設定と専用の一時状態ファイルを使って検証すると、本番の状態ファイルを汚しにくくなります。
-fによる強制実行は、ログの切替、圧縮、削除、postrotateを実行する可能性があります。本番ログではバックアップと影響確認を先に行ってください。