Linuxのlogrotate設定を放置してディスクが溢れた日の話｜ログ管理を習慣化するまでに払ったコスト

「サーバーのディスクが満杯になってWebサービスが止まりました。ログが原因みたいですが、どう対処すれば……」

これは、私がLinuxセミナーを開催するたびに受講生から聞かれる質問の一つです。セミナーで3,100名以上を指導してきた中で、この「ログによるディスクフル」は、Linuxを本番環境で使い始めたエンジニアが必ずといっていいほど一度は経験する洗礼のようなものだと感じています。私自身、2002年頃のSE時代に同じ失敗をやらかして、深夜に冷や汗をかいた苦い記憶があります。

この記事では、私が実際に体験したlogrotate設定を放置したことによるディスクフル障害の経緯と、その失敗から身につけたログ管理の習慣について解説します。「ログはそのうち整理すればいい」と思っているエンジニアの方に、ぜひ読んでほしい内容です。

ログファイルが静かにディスクを食い続ける理由

Linuxサーバーでは、アプリケーションやシステムが常時ログを書き出しています。Apacheのアクセスログ、メールサーバーのログ、cronのジョブ記録、sshdの認証ログ、systemdのjournalログ……これらは放置すると毎日少しずつ積み上がり、いつの間にかディスクを圧迫します。

問題は、こうしたログの肥大化が「静かに」進むことです。CPUやメモリの使用率なら監視ツールがアラートを出してくれますが、ディスク容量の監視を後回しにしているサーバーは珍しくありません。気づいた時にはもう手遅れで、No space left on deviceというエラーとともにWebサービスが止まっていた、という事態になりやすいのです。

Linuxにはこの問題を自動で解決する仕組みとして、logrotate（ログローテーション）が用意されています。ログファイルを定期的に圧縮・分割・削除して、常に一定のディスク容量を保つためのツールです。多くのディストリビューションではデフォルトでインストールされていますが、設定が適切でなければ機能しません。構築したサーバーのlogrotate設定を一度も確認しないまま運用しているエンジニアは、意外と多いものです。

なぜ設定を放置してしまうのか。理由は単純で、「ログが溢れるまで何も起きないから」です。構築直後はディスクに余裕があり、ログが問題になるのは数ヶ月後から数年後。その頃には担当者が変わっていることもある。こうして「誰も確認していないlogrotate設定」が引き起こす障害が、現場で繰り返されています。私が現場でよく見かけるのが、設定ファイルにrotate 4とだけ書かれていて、ローテーション頻度（daily / weekly）が書かれていないケースです。この場合はデフォルトの週次が適用されますが、メール量の多いサーバーでは週次ではとても追いつきません。

SE時代にlogrotateを無視して本番が止まった夜の話

私がSEとして働いていた2002年頃の話です。当時、Linuxサーバーを使ったメールシステムの運用を任されていました。Linuxを使い始めてまだ1年ほどで、サーバー構築は先輩エンジニアに教わりながらなんとかこなした状態。「ログは溜まったら手で消せばいい」くらいの認識で、logrotateの設定などまともに見ていませんでした。

深夜の警告メールと焦りの初動

深夜0時過ぎ、携帯電話が鳴りました。監視システムからのアラートで「メールサーバーが応答しない」という内容です。眠い目をこすりながらサーバーにSSH接続すると、コマンドを打つたびに奇妙な挙動をします。

「write error」「cannot create temp file for here-document」といった見慣れないエラーが次々と出てきました。当時の私には何が起きているのか全然分からず、とにかく上司に電話しました。寝起きで機嫌の悪い声で一言、「dfで見てみろ」と言われました。

dfコマンドで見た衝撃の数字

言われるがままdf -hを実行した結果がこれです。
/（ルートパーティション）の使用率が100%です。Availの列には0と表示されています。「なんで満杯になってるんだ？」と/var/logを見てみると、Postfixのログファイルが1ファイルで18GB近くになっていました。毎日何千通ものメールが行き交うメールサーバーで、6ヶ月以上ログをローテーションしていなかったのです。

ログを手動削除したことで二次被害が起きた話

「ログを消せばディスクが空く」と判断した私は、rm /var/log/maillogを実行しました。コマンドは通り、df -hでも空きが増えたように見えました。しかし、Postfixはまだそのファイルを開いたままでした。

Linuxではファイルを削除しても、そのファイルを開いているプロセスが存在する間は実際のディスク領域は解放されません。df -hでは空きが増えたように見えても、実際にはまだディスクが使われている状態です。私はしばらく「あれ、まだおかしい」と悩み続け、結局Postfixを再起動してやっとディスクが解放されました。上司からは「次回はサービスを再起動するか、そもそもこういう事態にならないようlogrotateをちゃんと設定しておけ」と諭されました。

この夜の経験は、今でも鮮明に覚えています。セミナー受講生から同じ質問を受けるたびに、「あ、自分と同じ道を歩んでいる」と感じて、できる限り丁寧に説明するようにしています。「rm で消したのに空かない」という誤解は、今も現場でよく見かける典型的なハマりポイントです。

logrotateの設定を見直して再発を防いだ手順

障害の翌朝、上司の指示のもとでlogrotateの設定を徹底的に見直しました。その時に学んだ手順を共有します。

1. logrotateの設定ファイルを確認する

まずメインの設定ファイルと、アプリケーション別の設定ディレクトリを確認します。
設定ファイルの主なパラメータを理解しておくことが重要です。
・daily / weekly / monthly：ローテーションの頻度を指定する
・rotate N：保持するログの世代数。rotate 30なら最新30世代を保持する
・compress：古いログファイルをgzipで圧縮してディスクを節約する
・missingok：対象ファイルが存在しなくてもエラーにしない
・notifempty：空のファイルはローテーションしない
・delaycompress：直前のログ（まだ書き込み中の可能性あり）は圧縮を1世代遅らせる
・postrotate / endscript：ローテーション後に実行するコマンド（サービスへのシグナル送信など）

2. ローテーション設定を本番向けに調整する

障害の原因となったメールログには、以下のような設定が入っていました（当時の設定に近い形で再現しています）。
ローテーションの頻度も世代数も指定されていないため、デフォルト設定（週次・4世代）が適用されていました。しかし実際には週次ではローテーションが実行されておらず、長期間ログが蓄積された状態でした。修正後の設定はこうなりました。
dailyで毎日ローテーション、rotate 30で30日分を保持（30日を超えた分は自動削除）、compressで圧縮してディスクを節約する設定です。

3. logrotate --debugで事前に動作確認する

設定変更後は、必ず--debugオプションで動作をシミュレーションしてから本番適用します。
--debugモードでは実際のローテーション処理は行われず、「何が起きるか」だけが標準出力に表示されます。設定ミスで意図しないファイルが削除されることを防ぐための重要なステップです。設定変更のたびにこれを実行する習慣をつけることを強くお勧めします。

トラブルが起きたときのディスクフル診断と対処手順

logrotateを正しく設定していても、アプリケーションのバグや大量のエラー出力でディスクフルになることはあります。そういった緊急時のための手順を押さえておきましょう。20年以上サーバーを運用してきた経験から言うと、この手順を体で覚えているかどうかで、障害対応の速さが3倍以上変わります。

1. dfで全体の空き容量を把握する

まず状況を把握します。どのパーティションが問題なのかを特定するところから始めます。
Use%が90%を超えているパーティションが問題箇所です。上の例では/varが98%で危険な状態です。

2. duで容量を食っているディレクトリを特定する

問題のパーティションが分かったら、duコマンドで容量の大きいディレクトリを絞り込みます。
これで「Apacheのアクセスログが42GB」という犯人が特定できました。

3. ログファイルを安全に削除する方法

ここで注意が必要です。Webサーバーやアプリケーションが起動中にrmでログファイルを削除しても、プロセスがファイルディスクリプタを握っているため、ディスク領域は解放されません。私がSE時代にやらかした失敗がまさにこれです。

安全に解放するには、ファイルの中身を空にする（truncate）か、ファイルを削除してサービスを再起動する方法を使います。
truncate -s 0や> ファイル名（リダイレクト）はファイルの中身を空にするコマンドです。ファイル自体は残ったままなので、サービスがそのまま書き込みを続けられます。プロセスを止めたくない場面ではこちらが安全です。私はこの方法を障害から学んで以来、ずっと使い続けています。

また、lsof | grep deletedを使うと、削除済みだがプロセスに掴まれているファイルを確認できます。「rmしたのにdfの空きが増えない」という場合はこれで確認してみてください。

ログ管理を習慣化して得た3つの変化

あの深夜障害から20年以上が経った今、ログ管理についての考え方がどう変わったかをお伝えします。

1. サーバー構築直後にlogrotateの設定確認をリスト化した
新しいサーバーを構築したら、その日のうちにlogrotateの設定ファイルを確認することをルール化しました。特にアプリケーションを新しくインストールした場合、そのアプリのlogrotate設定が追加されているかを必ずチェックします。/etc/logrotate.d/にアプリ名のファイルがなければ、その場で作成してしまいます。この確認作業は5分もあればできるので、後回しにする理由がありません。

2. ディスク使用率の監視をアラートに組み込んだ
使用率が80%を超えたら警告、90%を超えたら緊急アラートとして通知が届くように設定しました。以前は「CPU・メモリ・死活監視」がセットでしたが、今は必ず「ディスク使用率監視」もセットです。夜中に突然止まって慌てるより、日中にアラートで気づいて余裕を持って対処する方が何倍も楽です。簡単なシェルスクリプトとcronで実装するだけで十分です。

3. 「ログは長く残すほど良い」という思い込みを捨てた
かつては「ログはできるだけ長く残したい」という発想がありました。しかしlogrotate設定を見直す中で気づいたのは、古いログの大半は実務で参照しないということです。3ヶ月前のアクセスログを分析することはほぼない。必要な保存期間を見極めて、不要な分は自動で削除するように設定を整えることで、「ログの量」よりも「ログの使いやすさ」が劇的に上がりました。

受講生からよく聞かれる「ログってどれくらい残せばいいですか？」という質問への私の答えは、「業務でさかのぼることが現実的な期間だけ残す」です。セキュリティ要件がなければ、Apacheのアクセスログは30日、メールログは60日、認証ログ（secure）は90日程度が現場での目安になります。これを超えた分はディスクの無駄遣いです。

logrotateの設定は一度やれば終わりではなく、アプリケーションを追加するたびに見直しが必要です。この習慣を持てるようになったことが、あの深夜障害から得た最大の収穫だったと今は思っています。

まとめ

logrotateの設定を一度も見直さずに運用を続けることは、じわじわと水が溜まる浴槽の栓を開け忘れているようなものです。ある日突然溢れて大変なことになる。

私のSE時代の失敗が、少しでも参考になれば幸いです。dfコマンドの詳しい使い方や、logrotateの設定詳細は関連する技術記事も合わせてご覧ください。

やりたいこと	コマンド・手順
ディスク使用状況を確認する	df -h
容量を食っているディレクトリを特定する	du -sh /var/* | sort -rh | head -10
logrotate設定を確認する	cat /etc/logrotate.conf && ls /etc/logrotate.d/
logrotateの動作をデバッグ確認する	logrotate --debug /etc/logrotate.conf
ログファイルを安全に空にする	truncate -s 0 /var/log/xxx.log
logrotateを手動で強制実行する	logrotate -f /etc/logrotate.conf

---

• 前のページへ：Linuxのumaskを知らずに新規ファイルの権限がバラバラだった日の話｜「なぜ644で作られるのか」を理解するまでの実務経験
• この記事の属するカテゴリ：Linux学習ガイドへ戻る