- 更新日: 2016年4月12日
- CentOS & Linux
rmでファイル削除後にdf -hで容量が減らない時の対処(Linux)
rm コマンドでファイルを削除した後に、df -h コマンドでディスク容量を確認したところ、容量が全く減らない現象に遭遇しました。結論から言いますと、何かしらのプロセスが使用中のファイルを rm コマンドで削除しても、ls や find コマンドで表示されなくなるだけで、実際にはファイルシステム上から削除されていないということらしい。
画像付き英語辞書 Imagict | 英単語をイメージで暗記df -h コマンドでディスク使用状況を確認
管理している Ruby 製のウェブアプリケーションが動いているサーバーで、ログローテーションの設定が行われておらず、ログファイルの容量が大変なことになっているサーバーがありました。最終的に、Ruby の Logger が吐き出していた、1つのログファイルが約50GBになってることを確認してちょっと驚いた。そのでかいログファイルを削除した時に起こった事象です。
ということで、そのログファイルを削除する前の段階。まずは、df -h でディスクの使用状況を確認しました。
|
1 2 3 4 5 6 |
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 98G 57G 36G 62% / tmpfs 938M 0 938M 0% /dev/shm |
50GB 以上が使用されており、このサーバーの場合ですとちょっとありえない状況。この時点で、原因は何かのログファイルだろうなと予測を付けた。
du コマンドで容量が大きいファイルを調査
du コマンドを使って、容量が大きいファイルを突き止めます。
|
1 2 3 |
$ sudo du -h --max-depth=1 / |
上コマンドの例では、ルートパスを対象に du コマンドで、容量が圧迫しているディレクトリを調査しています。このコマンドはディスクI/Oの負荷が生じるので、最初から予測が付く場合は調査対象のディレクトリパスを、絞り込むなどを行うほうが良いかと思います。
|
1 2 3 |
$ sudo du -h --max-depth=1 /var/ |
など。
この結果 /path/to/hogefuga.log のログファイルが約50GBになってて、容量を圧迫していたことが判明しました。
ということで /path/to/hogefuga.log を一旦削除して作成やりなおし。
|
1 2 3 4 |
$ rm /path/to/hogefuga.log $ touch /path/to/hogefuga.log |
これで、hogefuga.log は空っぽになって容量が空いてるはず、と思いきや！
|
1 2 3 4 5 6 |
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 98G 57G 36G 62% / tmpfs 938M 0 938M 0% /dev/shm |
再び df -h コマンドでディスク使用を確認したところ、変わっておらず。容量が削減されたはずなのですが、それが反映されない状態です…なんでや。
なぜ、このような現象が起きるのかといいますと、
Linux のファイルシステムでは、rm コマンドでファイルを削除したとしても、その削除したファイルをプロセスが使用中であった場合は、実際にはファイルシステム上から削除されず、ls や find のコマンドで表示されなくなるだけだから、ということです。
なので、rm で削除したファイルをプロセスが使用している状態から、解放してやる必要がある。つまり、その削除したファイルを使用中のプロセスを kill してやる必要があります。可能であれば、サーバーを再起動させる方法でもOK。
lsof コマンドでログファイルを使用中のプロセスを調査
sudo で lsof コマンドで、対象ファイルを使用中のプロセスを調査します。
|
1 2 3 4 5 6 7 |
$ sudo lsof | grep hogefuga.log ruby 10041 user 9w REG 253,1 52132273180 10059813 /path/to/hogefuga.log (deleted) ruby 16947 user 9w REG 253,1 52132273371 10059813 /path/to/hogefuga.log (deleted) ruby 24665 user 9w REG 253,1 52132273462 10059813 /path/to/hogefuga.log (deleted) ... |
hogefuga.log は Ruby の Logger クラスが吐き出していたログだったのですが、ruby のプロセス自体が hogefuga.log を使用中であった。ということで、夜中のアクセスが少ないうちに、サーバーを再起動して対処しました。
サーバー再起動が無理な場合は、個別にプロセスIDを指定して kill していく。
|
1 2 3 4 5 |
$ kill 10041 $ kill 16947 $ kill 24665 |
サーバー再起動で上手くいったので、この個別にプロセスを kill していく方法のほうは試していません。
その後、もう一回 df コマンドでディスク容量の確認。
|
1 2 3 4 5 6 |
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 98G 8.1G 85G 9% / tmpfs 938M 0 938M 0% /dev/shm |
減りました！使用中（Used）の容量が、約50GBが減ったことを確認できました。これで一安心です。この後、ログローテートの設定を行いまして対応終了。
- – 参考リンク –
- kakakikikekeのブログ: 【Linux】rmとかmvしてもdfでディスクの容量が減らないときの対処方法
- ファイルを消してもディスク容量が減らない場合の対応 – ベリラボ – wiki
- CentOS & Linux の関連記事
- Job for nginx.service failedのNginxエラー
- upstream sent too big header while reading response header from upstream(Nginx/Rails)
- Can’t get information about user clamav(clamdエラー)
- STDERR: Exception in thread “main” java.lang.InternalErrorエラー
- Linuxサーバー容量を確認するコマンドdf,duをマスターする！
- Apacheをローカルネットワークのみに公開にする
- logwatchからのメールが来ないと思ったら…
- Linuxサーバの負荷や使用率を調査するコマンドと手順
- Bashの脆弱性もう一件CVE-2014-7169に対するパッチ適用
- Bash脆弱性に対してChefでbashをアップデートしてパッチ適用
- 初回公開日: 2016年4月8日
Leave Your Message!