ディスク満杯の調査と対処
「書き込めない」「サービスが起動しない」障害の典型原因がディスク満杯です。まず df -h で各マウントポイントの使用率を見て、100%に近い領域を特定します。次に du で原因のディレクトリを上から掘り下げ、肥大化したファイルを突き止めます。よくある犯人は伸び続けるログファイルや古いキャッシュです。なお、削除してもプロセスがファイルを開いたままだと容量が戻らないことがあり、その場合は lsof で開いているプロセスを確認します。
「ファイルに書き込めない」「サービスが急に起動しなくなった」「ログが記録されない」――この一見バラバラな障害には、意外なほど多くの共通原因がある。
その正体がディスク満杯だ。ディスクの空きが尽きると、プログラムは新しいファイルを作れず、既存ファイルへの追記もできなくなる。だから影響が思わぬところに飛び火する。
しかもエラーメッセージが直接「ディスクが満杯です」と言ってくれるとは限らず、別の症状として現れることも多い。原因不明の不調に出会ったら、ディスク使用量の確認を切り分けの早い段階に入れておくと近道だ。
💽 どの領域が満杯か、df で一覧する
まず全体像を df で確認する。df は disk free の略で、ファイルシステム（マウントされた各領域）ごとの容量と使用状況を一覧する。
df -h と人間に読みやすい単位を付けて実行すると、Filesystem（デバイス名）、Size（総容量）、Used（使用量）、Avail（空き）、Use%（使用率）、Mounted on（マウント先のパス）が表形式で並ぶ。
ここで Use% が100%、あるいはそれに近い領域を探す。たとえば / が100%なのか、/var だけが満杯なのか、/home が逼迫しているのかで、次に掘る場所が決まる。
Linuxは複数のディスクや領域を別々のパスにマウントできる。そのため「全体ではまだ空いているのに、特定の領域だけ満杯」というケースがよくある点に注意する。
🔦 何が容量を食うか、du で掘る
満杯の領域が分かったら、その中の「何が」容量を食っているかを du で突き止める。du は disk usage の略で、ディレクトリが使っている容量を集計する。
やみくもに使うと出力が膨大になるので、上の階層から順に掘り下げるのがコツだ。
たとえば du -h --max-depth=1 /var のようにすると、/var の直下にある各ディレクトリの合計サイズが1段だけ表示され、どこが大きいかが分かる。
一番大きいディレクトリ（たとえば /var/log）が見つかったら、今度はそこを対象に同じコマンドを実行し、さらに一段深く掘る。これを繰り返して、肥大化したファイルやディレクトリへ絞り込んでいく。
大きい順に並べたいときは du -h --max-depth=1 /var | sort -h のように sort -h（人間可読な単位でソート）をつなぐと見やすくなる。
よくある犯人は、伸び続けるログファイル（とくにログローテーションが効いていないアプリのログ）、溜まり続ける古いキャッシュや一時ファイル、肥大化したデータベースのファイル、消し忘れた巨大なバックアップやダンプファイルなどだ。
du で大きなファイルを特定できたら、本当に消してよいものかを確認したうえで、不要なものを削除したり、ログをローテーション・圧縮したりして空きを取り戻す。
なお、ディスクが満杯に近づくと書き込みが詰まり、システム全体の性能を頭打ちにするボトルネックにもなり得る。容量の確保は、単に「書けるようにする」だけでなく、性能面でも効いてくる対処だと捉えておくとよい。
👻 消したのに容量が戻らない
ディスク満杯対応で初学者が必ずと言ってよいほどはまる落とし穴がある。大きなログファイルを rm で削除したのに、df を見ても空きがまったく増えない、という現象だ。
原因はLinuxのファイルの扱い方にある。あるプロセスがファイルを開いている（読み書きのために掴んでいる）と、そのファイルへの参照が「ファイルディスクリプタ」という形で保持される。
ファイルディスクリプタとは、プロセスが開いているファイルやソケットに割り当てられる管理番号のことだ。
ファイル名を rm で消しても、それを開いたままのプロセスが残っていると、ディスク上の実体は解放されず、容量も戻らない。
実体が本当に消えるのは、最後にそのファイルを開いていたプロセスがファイルを閉じる（または終了する）瞬間だ。
この状態を確認するのが lsof（list open files）だ。lsof +L1 とすると、「削除済みなのにまだ開かれているファイル」を一覧でき、どのプロセス（とPID）がそれを掴んでいるかが分かる。
原因のプロセスが特定できたら、そのプロセスを再起動するか、安全に終了させると、掴んでいたファイルが解放され、ようやくディスクの空きが戻る。
サービスのログでこれが起きている場合は、サービスを再起動するか、ログのローテーション時にサービスへログの開き直しを通知する仕組み（多くは logrotate の設定）を整えるのが正攻法だ。「消したのに減らない」を知っているだけで、無駄に悩む時間を大きく減らせる。
🧮 容量はあるのに書けない、もう一つの満杯
もうひとつ知っておきたいのが、容量はまだあるのに「書き込めない」ケースだ。
ファイルシステムは、ファイルの実データとは別に、1ファイルにつき1つ「inode」という管理情報の枠を消費する。
小さなファイルが極端に大量にあると、データ容量より先にこの inode を使い切ってしまい、空きはあるのにファイルを作れなくなる。
df -h で Use% に余裕があるのに書き込めないときは、df -i で inode の使用率（IUse%）を確認する。ここが100%なら inode 枯渇だ。
原因はたいてい、一時ファイルやセッションファイルが大量に溜まっているディレクトリなので、不要な小ファイルを整理して解消する。
🗺 ディスク障害の調査の王道
ディスク関連の調査は、df → du → （必要なら）lsof の順が王道だ。
まず df -h で満杯の領域を特定し、du -h --max-depth=1 で原因ディレクトリを段階的に掘り、肥大化したファイルを突き止めて対処する。
消したのに空きが戻らなければ lsof +L1 で削除済みファイルを掴むプロセスを探す。df -h で問題ないのに書けないなら df -i で inode を疑う。この分岐を覚えておけば、ディスク起因の障害はかなりの確率で自力で解決できる。
日頃から df をたまに眺めて、満杯になる前に手を打つ習慣をつけておくと、そもそも障害として顕在化させずに済む。