― rotate が動かない時の原因切り分けまでの手順の備忘録 ―

はじめに

サーバーを長期間運用していると、NGINX やアプリケーションのログが肥大化し、
ディスク枯渇や I/O 負荷の原因になります。

Linux では logrotate を使ってログの自動ローテーションを行うのが定石ですが、

• 設定したつもりなのにログが回らない
• cron では実行されているように見える
• それでもログが巨大化し続ける

といったトラブルに遭遇しがちです。

この記事では、

• logrotate の基本構造
• Debian系(Ubuntu等) における正しい実行方式（systemd）
• 設定項目の意味
• NGINX の正しい設定例
• 「rotate されない」時の実践的トラブルシューティング

をまとめます。

logrotate の基本構造

logrotate は「設定を読むだけ」のツール

logrotate 自体は常駐しません。

logrotate 設定ファイルを読む
↓
条件を満たせばログを rotate
↓
終了

定期実行する仕組みは別に存在します。

logrotate の実行方式（重要）

cron ではなく systemd timer が標準

Ubuntu では logrotate は systemd timer により自動実行されています。

logrotate.timer
↓
logrotate.service
↓
/usr/sbin/logrotate /etc/logrotate.conf

確認コマンド：

cron で手動実行は不要（むしろ危険）

以下のような設定は 原則不要です。

理由：

• systemd と cron が 同じ state ファイルを使う
• 「今日は既に rotate 済み」と判断される
• 見た目は実行されているのに rotate されない

logrotate の設定ファイル構成

親設定
/etc/logrotate.conf

中身（一部）：

include /etc/logrotate.d

個別設定（ここが重要）

⚠ 注意：ディレクトリは読まれない

logrotate は再帰しません。

❌ 間違い：

/etc/logrotate.d/nginx/logrotate.conf

✅ 正解：

/etc/logrotate.d/nginx

ファイル名・拡張子（.conf など）は自由です。

logrotate 設定項目の基本解説

頻度・世代管理

サイズ条件

※ size があると「日次でもサイズ未達なら回らない」

圧縮・削除関連

NGINX での logrotate 設定例（重要）

なぜ postrotate が必要か

• NGINX はログファイルを 起動時に open したまま書き続けます。
• logrotate が rename する
• nginx は古い inode に書き続ける

→ ログが肥大化して見える

kill -USR1 を送ることで
ログファイルを reopen させます。

copytruncate との違い

• nginx 再起動不要
• ただしコピー＋truncate で I/O が増える
• 高トラフィック環境では非推奨

rotate が機能しない時のトラブルシューティング

① systemd timer が動いているか

② 設定ファイルが読まれているか

出力に以下が出るか：

出ない場合：

• 配置場所が間違っている
• ディレクトリ配下に置いている

③ 強制実行で動作確認

rotating pattern: → 正常

skipping のみ → 条件未達 or state 問題

④ サイズ条件に引っかかっていないか

→ テスト時は一時的に：

⑤ nginx がログを掴み続けていないか

• `postrotate` があるか
• `nginx.pid` のパスは正しいか

⑥ state ファイル競合

cron 併用している場合：

• systemd に一本化する
• もしくは -s で state 分離

よくある勘違いまとめ

まとめ（結論）

• Ubuntu等debian系 では logrotate は systemd に任せる
• 設定は /etc/logrotate.d 直下にファイルで置く
• NGINX は必ず USR1 で reopen させる
• logrotate -v は最強のデバッグ手段

logrotate は「静かに失敗する」ツールなので、
配置と実行経路の理解が最重要です。

以上。
この内容を押さえておけば、logrotate で詰まることはほぼ無くなります。