Linuxでファイルを削除してもディスク容量が戻らない原因と対処法
Linuxサーバーで不要なログファイルやデータを削除したのに、ディスクの空き容量が増えないことがあります。
rm コマンドでファイルを削除したはずなのに、df で確認すると使用量がほとんど変わらない。このような場合、削除したファイルを実行中のプロセスが開いたまま保持している可能性があります。
Linuxでは、ファイル名を削除しても、そのファイルを使用しているプロセスが存在すると、実際のディスク領域がすぐに解放されないことがあります。
ここでは、df と du の違いから、lsof を使った原因の調査、ディスク容量を安全に解放する方法まで順番に説明します。
ファイルを削除したのにディスク容量が減らない原因
Linuxでファイルを削除しても容量が減らない主な原因は、削除したファイルをプロセスが引き続き開いていることです。
例えば、サーバーのログファイルが大きくなったため、次のように削除したとします。
sudo rm /var/log/application.log通常はファイルが削除され、使用していたディスク領域も解放されます。
しかし、ログを書き込んでいるアプリケーションやサービスが、そのファイルを開いたままの場合は状況が異なります。
Linuxでは、ファイル名が削除されても、ファイルを開いているプロセスが存在する間はデータが保持されます。
そのため、ディレクトリ上ではファイルが見えなくなっているのに、ディスク容量は使用されたままになることがあります。
1. dfとduでディスク使用量の違いを確認する
まずは、df と du を使ってディスク使用量を確認しましょう。
この2つのコマンドは、確認している対象が異なります。
| コマンド | 確認する内容 |
|---|---|
df | ファイルシステム全体の使用量 |
du | 指定したディレクトリやファイルの使用量 |
dfでディスク全体の使用量を確認する
次のコマンドを実行します。
df -h表示例：
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 50G 42G 8.0G 84% /主な項目は次のとおりです。
- Size：ファイルシステム全体の容量
- Used：使用中の容量
- Avail：利用可能な容量
- Use%：使用率
- Mounted on：マウント先
ファイルを削除した後も Used の数値が変わらない場合は、削除したファイルがまだプロセスに保持されていないか確認します。
duでディレクトリごとの使用量を確認する
次に、ディレクトリごとの容量を調べます。
sudo du -sh /var/logサーバー全体で容量の大きいディレクトリを探す場合は、次のように実行できます。
sudo du -xhd1 / 2>/dev/null-x は別のファイルシステムにまたがらないようにするオプション、-d1 は1階層分のディレクトリを表示する指定です。
このコマンドはGNU版の du を前提としています。環境によってオプションが異なる場合があります。
dfとduの結果が一致しない場合
df では大量の容量が使用されているのに、du で調べたディレクトリの合計が少ない場合は、削除済みファイルが開かれたままになっている可能性があります。
ただし、これだけで原因を断定することはできません。
ファイルシステムのメタデータ、予約領域、スナップショット、別のマウントポイントなども差が生じる要因になります。
次は lsof を使って、削除済みファイルを保持しているプロセスを調べます。
2. lsofで削除済みファイルを確認する
削除したファイルをプロセスが開いたままにしているか調べるには、lsof コマンドが便利です。
まず、次のコマンドを実行します。
sudo lsof | grep deleted削除済みファイルを開いているプロセスがあれば、次のような情報が表示されることがあります。
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nginx 1234 root 5w REG 253,0 524288000 1234 /var/log/nginx/access.log (deleted)※数値やファイル名は説明用のサンプルです。
主な項目は次のとおりです。
- COMMAND：ファイルを開いているプロセス名
- PID：プロセスID
- USER：プロセスの実行ユーザー
- FD：ファイルディスクリプタ
- SIZE/OFF：ファイルサイズまたはオフセット
- NAME：ファイル名
末尾に (deleted) と表示されている場合、ファイル名は削除されていますが、プロセスがファイルを開いたまま保持している可能性があります。
大きな削除済みファイルだけを探す
すべての結果を確認するのが大変な場合は、サイズ情報に注目しましょう。
sudo lsof -nP +L1+L1 はリンク数が1未満のファイルを表示する指定で、削除済みファイルの調査に役立ちます。
-nP はホスト名やポート番号の名前解決を行わず、数値のまま表示するオプションです。
出力に表示された SIZE/OFF や PID を確認し、どのプロセスが容量を保持しているか調べます。
なお、SIZE/OFF は必ずしも実際に解放されていないディスクブロックの容量と一致するわけではありません。
3. 削除済みファイルを保持しているプロセスを特定する
lsof で削除済みファイルが見つかったら、次はプロセスを確認します。
例えば、次のような記録が表示されたとします。
nginx 1234 root 5w REG 253,0 524288000 /var/log/nginx/access.log (deleted)この場合、確認するポイントは次の3つです。
- プロセス名：nginx
- PID：1234
- ファイル名：access.log
まず、プロセスの詳細を確認します。
ps -fp 12341234 の部分は、実際に表示されたPIDに置き換えてください。
さらに、どのサービスに関連するプロセスなのか確認します。
systemctl status nginxこの例ではNginxを使用していますが、実際にはログを保持しているプロセスに合わせてサービス名を変更してください。
プロセスが本当に必要か確認する
容量を解放したいからといって、すぐにプロセスを終了させるのは避けましょう。
Webサーバーやデータベースなどの重要なサービスを停止すると、サイトやアプリケーションが利用できなくなる可能性があります。
まずは対象のプロセスが何のために動いているのか、サービスへの影響がないか確認してください。
4. ディスク容量を安全に解放する方法
削除済みファイルを保持しているプロセスが特定できたら、状況に応じて容量を解放します。
代表的な方法は、対象サービスを再起動することです。
方法① サービスを再起動する
例えば、Nginxが削除済みのログファイルを保持している場合は、サービスの再起動によってファイルが閉じられ、容量が解放されることがあります。
sudo systemctl restart nginxただし、再起動すると一時的に接続が切れる可能性があります。
本番環境では、アクセス状況やサービスへの影響を確認してから実施してください。
再起動後は、次のコマンドで容量を確認します。
df -hまた、削除済みファイルが残っていないか再度調べます。
sudo lsof -nP +L1方法② アプリケーションのログ出力を再読み込みする
サービスによっては、再起動せずにログ出力先を再読み込みできる場合があります。
例えば、Nginxでは次のコマンドで設定やログ出力先を再読み込みできます。
sudo systemctl reload nginxただし、reload が削除済みファイルの解放につながるかどうかは、サービスの実装や設定によって異なります。
確実に解放される方法として一律に扱わず、必要に応じてサービスの公式ドキュメントを確認してください。
方法③ ログローテーションを正しく設定する
ログファイルが大きくなり続ける問題を防ぐには、ログローテーションの設定も重要です。
Linuxでは一般的に logrotate が利用されています。
設定ファイルは次の場所にあります。
/etc/logrotate.conf
/etc/logrotate.d/Nginxなどのログ設定を確認する場合は、次のように実行します。
ls -l /etc/logrotate.d/ログローテーションを適切に設定すれば、ログファイルが際限なく大きくなるのを防ぎやすくなります。
ただし、ログローテーション後もプロセスが古いファイルを開いたままにしていると、同じ問題が発生する場合があります。
サービス側でログを再オープンする仕組みも確認しておきましょう。
5. 削除済みファイルが見つからない場合に確認すること
lsof で削除済みファイルが見つからない場合は、別の原因も考えられます。
次の項目を確認してみてください。
別のマウントポイントを確認する
サーバーでは、/、/var、/home などが別々のファイルシステムとしてマウントされている場合があります。
次のコマンドでマウント状況を確認できます。
df -hT容量が不足しているファイルシステムを特定し、そのマウント先を中心に調べましょう。
ディレクトリごとの容量を再確認する
次のコマンドで、対象のファイルシステム内にある容量の大きなディレクトリを確認します。
sudo du -xhd1 /var 2>/dev/null/var の部分は、調査したいディレクトリに変更してください。
ファイルシステムの予約領域を確認する
Linuxのファイルシステムでは、一般ユーザーが使用できる容量と、管理用に予約されている容量が異なる場合があります。
特にext4では、予約ブロックの設定によって df の表示に影響することがあります。
次のコマンドでファイルシステムの情報を確認できます。
sudo tune2fs -l /dev/sda1/dev/sda1 は実際のデバイス名に置き換えてください。
このコマンドはext2・ext3・ext4向けです。別のファイルシステムでは使用できません。
6. ファイル削除後の容量トラブルを防ぐ方法
同じ問題を繰り返さないためには、普段からログやファイルの管理方法を見直すことが大切です。
特にサーバーでは、次のような対策が役立ちます。
- ログローテーションを適切に設定する
- ログファイルの保存期間を決める
- ディスク使用率を定期的に監視する
- 不要なファイルを削除する前に使用中のプロセスを確認する
- アプリケーションのログ出力方法を見直す
ディスク使用率が高くなってから対応するのではなく、余裕があるうちに管理方法を整えておくと、突然の容量不足を防ぎやすくなります。
まとめ
Linuxでファイルを削除したのにディスク容量が減らない場合は、削除したファイルを実行中のプロセスが開いたままにしている可能性があります。
今回紹介した主な確認コマンドは次のとおりです。
| コマンド | 用途 |
|---|---|
df -h | ファイルシステム全体の使用量を確認 |
du -sh | ディレクトリやファイルの容量を確認 |
sudo lsof | grep deleted | 削除済みファイルを探す |
sudo lsof -nP +L1 | 開いたままの削除済みファイルを確認 |
ps -fp PID | 対象プロセスの詳細を確認 |
systemctl status サービス名 | 関連サービスの状態を確認 |
特に重要なのは、df と du の使用量に大きな差がある場合、lsof で削除済みファイルを調べることです。
原因となっているプロセスを特定したら、サービスへの影響を確認したうえで再起動やログ設定の見直しを行いましょう。
ファイルを削除するだけでなく、プロセスがそのファイルを使い続けていないか確認することが、Linuxサーバーのディスク容量を適切に管理するポイントです。
Linuxのディスク容量が足りないときの確認方法｜df・duで原因を調べる手順