【logrotate講座 第7回】動かない時の処方箋。デバッグモード活用とSELinux/ステータスファイルの罠

「何もしていないのに動かない」ことはない。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、権限（Permission）周りの複雑なトラブルを解決する方法を学びました。

しかし、logrotateのトラブルは権限エラーだけではありません。
「設定ファイルを書いたのに無視される」「手動実行（-f）なら動くのに、自動（cron）だと動かない」「エラーメッセージすら出ずに沈黙している」…
こうした「サイレント・トラブル」こそが、エンジニアの時間を最も奪う厄介な敵です。

本記事では、AlmaLinux 9 をベースに、デバッグモード（ドライラン）の出力結果の完全解読、ステータスファイルの仕組みと操作、そしてSELinuxによるブロックの解除方法まで、トラブルシューティングの奥義を解説します。

---

第1章：logrotateの脳内を見る「デバッグモード (-d)」

トラブルシューティングの第一歩は、「logrotateが何を考えているか」を知ることです。
-d (Debug) オプションを使うと、実際には処理を行わずに（ドライラン）、判定ロジックだけを表示してくれます。

実行コマンド

sudo logrotate -d /etc/logrotate.d/myapp

出力結果の読み解き方

大量のメッセージが出ますが、重要なポイントは以下の通りです。

1. 設定ファイルの読み込み

reading config file /etc/logrotate.d/myapp

まず、ファイルが正しく認識されているか確認します。
ここに error: ... が出ている場合は、構文ミス（括弧の閉じ忘れなど）です。

2. 対象ログの検出

considering log /var/log/myapp/access.log

ワイルドカードなどが正しく機能し、対象のログファイルが見つかっているか確認します。
ここに出なければ、パスの間違いか、ファイルが存在していません。

3. ローテーション要否の判定（最重要）

ここがトラブルの原因特定ポイントです。

  log does not need rotating (log has been already rotated)

意味： 「今日はもう回したから、まだ回す必要はないよ」
logrotateは1日1回しか回さない設定（daily）の場合、同日に2回目は実行しません。

  log does not need rotating (log is empty)

意味： 「ログが空っぽ（0バイト）だから回さないよ」
notifempty が設定されている場合の挙動です。

  log needs rotating

意味： 「よし、回すぞ！」
これが出ていれば、設定上の条件はクリアしています。

---

第2章：黒幕は「ステータスファイル」にあり

デバッグモードで「log has been already rotated（もう回したよ）」と言われて、「いやいや、テストしたいんだって！」と困ったことはありませんか？
logrotateは、過去の実行履歴を記録したステータスファイルを持っており、これを見て実行可否を決めています。

ステータスファイルの場所

AlmaLinux 9 など多くのディストリビューションでは以下にあります。

/var/lib/logrotate/logrotate.status

中身を見てみる

cat /var/lib/logrotate/logrotate.status

出力例：

logrotate state -- version 2
"/var/log/httpd/access_log" 2026-01-20-10:00:00
"/var/log/myapp/app.log" 2026-01-20-10:00:00

このように、「ファイル名」と「最後にローテーションした日時」が記録されています。

裏技：日付を改ざんして強制テスト

daily 設定の場合、ここの日付が「今日」だと実行されません。
テストのために無理やり実行させたい場合、このファイルを編集して日付を過去（昨日など）に書き換えるという手があります。

# vimなどで開いて日付を1日前に戻す
"/var/log/myapp/app.log" 2026-01-19-10:00:00

これで logrotate を実行すると、「おっ、1日経ってるな」と騙されて実行してくれます。
※もちろん、-f（強制実行）オプションを使えば日付関係なく実行できますが、この仕組みを知っておくことは重要です。

---

第3章：RHEL系のラスボス「SELinux」

設定も合っている、権限も合っている。手動実行（sudo logrotate ...）なら動く。
しかし、cronからの自動実行だけが失敗する。
このパターンの犯人は、十中八九 SELinux です。

なぜブロックされるのか？

SELinuxは、プロセスごとに「アクセスしていい場所」を厳格に決めています。
logrotateプロセスは、/var/log/ などの「標準的なログ置き場」へのアクセスは許可されていますが、「管理者が勝手に作ったディレクトリ（例：/home/admin/logs/）」への書き込みやリネームは「怪しい挙動」としてブロックします。

確認方法：拒否ログを見る

ausearch コマンドで、logrotateに関連する拒否（denied）ログを探します。

sudo ausearch -m avc -ts recent | grep logrotate

もし出力があれば、SELinuxにブロックされています。

解決策：正しいラベル（コンテキスト）を貼る

SELinuxに「ここはログ置き場だよ」と教えてあげる必要があります。
ログファイル用のラベルは var_log_t です。

手順：

# 1. 現在のラベルを確認（unconfined_u:object_r:user_home_t ... などになっているはず）
ls -Z /home/admin/logs/app.log

# 2. 正しいラベル定義を追加（恒久設定）
# /home/admin/logs/ 以下の全ファイルに var_log_t を適用するルールを追加
sudo semanage fcontext -a -t var_log_t "/home/admin/logs(/.*)?"

# 3. 定義を適用（リラベル）
sudo restorecon -Rv /home/admin/logs/

# 4. 確認
ls -Z /home/admin/logs/app.log
# system_u:object_r:var_log_t:s0  <-- var_log_t になっていればOK

これで、logrotate（およびSELinux）は、そこを正当なログファイルとして扱ってくれます。

---

第4章：強制実行 (-f) と 詳細表示 (-v) の活用

デバッグモード（-d）は「実際には実行しない」ため、ファイルの書き込み権限エラーなどは検出できないことがあります。
本番同様に書き込みを行いつつ、詳細なログを見たい場合は -v (Verbose) と -f (Force) を組み合わせます。

最強のテストコマンド

sudo logrotate -vf /etc/logrotate.d/myapp

• -v (Verbose): 処理内容を逐一画面に表示します。「今ファイルをリネームした」「今スクリプトを実行した」などが分かります。
• -f (Force): ステータスファイルの日付を無視して、強制的にローテーションを実行します。

これでエラーが出なければ、設定ファイルは完璧です。
実際にファイルがローテートされ、新しいログファイルにアプリが書き込めているかを確認しましょう。

---

第5章：よくある設定ミス集（FAQ）

最後に、初心者がやりがちな「うっかりミス」をまとめました。

1. 設定ファイルの権限が緩すぎる

/etc/logrotate.d/ 以下の設定ファイルは、セキュリティ上 rootユーザー以外が書き込める状態だと無視されます。

error: /etc/logrotate.d/myapp is writable by group or other

必ず 644 (rootのみ書き込み可) に設定しましょう。

sudo chown root:root /etc/logrotate.d/myapp
sudo chmod 644 /etc/logrotate.d/myapp

2. エディタのバックアップファイルが邪魔をする

vim などで編集していると、.swp や myapp~ といったバックアップファイルが作られることがあります。
logrotateはディレクトリ内の「全てのファイル」を読み込もうとするため、これらのゴミファイルを読み込んで「構文エラー」になることがあります。
不要なファイルは削除しましょう。

3. 親ディレクトリがない

olddir オプションで古いログの移動先を指定している場合、そのディレクトリが存在しないとエラーになります。
自動では作ってくれないので、mkdir しておく必要があります。

---

まとめ：トラブルシューティング・フローチャート

お疲れ様でした！
これで logrotate が動かない原因の99%は解決できるはずです。

解決フローチャート：

1. -d でデバッグ実行: 設定ファイルの構文と対象ファイルの認識を確認。
2. ステータスファイル確認: 「already rotated」なら -f で強制実行するか、ステータスファイルの日付をいじる。
3. -vf で実実行: 実際にファイルを動かしてみて、権限エラーが出ないか確認。
4. SELinux確認: 標準外のディレクトリなら semanage fcontext でラベルを貼る。
5. 設定ファイルの権限確認: chmod 644 になっているか。

さて、ここまでで logrotate の運用は完璧になりました。
しかし、ローテーションして圧縮したログも、サーバー内に置いておくだけでは、ディスク故障時に全て失われてしまいます。
また、古いログがサーバーに溜まり続けるのもリスクです。

次回、最終回となる第8回は「最強のバックアップ構築。S3への自動転送と一元管理への応用」です。
ローテーションしたログを、AWS S3などのクラウドストレージへ自動転送して永続化する方法や、複数サーバーのログを一箇所に集める設計思想について解説します。
最後の仕上げです。お楽しみに！