rmがディスク容量を解放しない
2.5gbのログファイルをrm 'edしましたが、空き領域がなかったようです。
やった：
rm /opt/Tomcat/logs/catalina.out
それからこれ：
df -hT
dfは私の/opt使用率100％のままです。
助言がありますか？
Tomcatを再起動します。ファイルが使用中の場合、削除すると、そのプロセスが終了したときにスペースが使用可能になります。
他の人が示唆したように、ファイルはおそらく他のプロセスによってまだ開かれています。どちらであるかを調べるには、次のことができます
lsof /opt/Tomcat/logs/catalina.out
プロセスをリストします。おそらくあなたはそのリストにTomcatを見つけるでしょう。
あなたの問題：
実行中のプログラムがまだファイルを保持している可能性があります。
あなたのソリューション：
ここでの他の回答によれば、Tomcatをシャットダウンしてファイルを保持しないようにすることができます。
それがオプションではない場合、または単に詳細が必要な場合は、次の質問を確認してください： 開いているが削除された大きなファイルを見つけて削除する -それに対処するためのいくつかの厳しい方法を提案しますあなたの状況により役立つかもしれません。
詳細：
Linux/unixファイルシステムは、「開かれた」ファイルをそれらの別名と見なします。 rmは、ディレクトリツリーに表示されるファイルから「名前」を削除します。ハンドルが閉じられるまで、ファイルにはまだ「名前」があり、ファイルはまだ存在しています。ファイルシステムは、ファイルの名前が完全に削除されるまでファイルを取得しません。
少し奇妙に思えるかもしれませんが、この方法でシンボリックリンクを有効にするなどの便利なことができます。シンボリックリンクは、基本的に同じファイルの代替名として扱うことができます。
これは、ファイルハンドルを使用する場合は、close（）と同等の言語を常に呼び出すことが重要な理由です。これにより、ファイルが使用されなくなったことがOSに通知されます。 これは役に立たない場合もありますが-Tomcatの場合がそうです。 Bill Karwin's Answer を参照して、理由を読んでください。
ファイルシステムに応じて、これは通常、一種の参照カウントとして実装されるため、実際の名前は含まれない場合があります。また、stdinやstderrのようなものがファイルまたは別のバイトストリーム（ほとんどの場合はサービスで行われます）にリダイレクトされると、奇妙になります。
この考え全体は ' inodes 'の概念に密接に関連しているため、好奇心が強いタイプの場合は、まずそれを確認することをお勧めします。
討論
これはあまりうまく機能しませんが、以前はOS全体を更新し、新しいライブラリを使用して新しいhttp-daemonを起動し、クライアントがサービスを提供しなくなったら古いものを最後に閉じることができました（リリース古いハンドル）。 httpクライアントはビートを見逃すことさえありません。
基本的に、実行中のプログラムを「下から」カーネルとすべてのライブラリを完全に消去できます。しかし、古いコピーには「名前」がまだ存在しているため、その特定のプログラムのファイルはメモリ/ディスクにまだ存在しています。次に、すべてのサービスを再起動するなどの問題が発生します。これは高度な使用シナリオですが、Unixシステムで何年もの稼働時間が記録されている理由です。
Tomcatを再起動すると、Tomcatがファイルに保持しているホールドが解放されます。ただし、Tomcatの再起動を避けるため（たとえば、これが実稼働環境であり、サービスを不必要に停止させたくない場合）、通常はファイルを上書きするだけです：
cp /dev/null /opt/Tomcat/logs/catalina.out
またはさらに短く、より直接的に：
> /opt/Tomcat/logs/catalina.out
トラブルシューティングやディスクのクリアの過程で、現在実行中のサーバープロセスのログファイルをクリアするために、これらの方法を常に使用しています。これにより、iノードはそのままになりますが、実際のファイルデータは消去されますが、ファイルを削除しようとしても機能しないか、少なくとも実行中のプロセスのログライターが混乱することがよくあります。
FerranBとPaul Tomblinがこのスレッドで指摘したように、ファイルは使用中であり、ファイルが閉じられるまでディスク領域は解放されません。
問題は、ファイルハンドルがJavaプロセスの制御下にないため、Catarinaプロセスにシグナルを送ってcatalina.outを閉じることができないことです。シェルI/Tomcatの起動時のcatalina.shでのリダイレクトCatalinaプロセスを終了することによってのみ、そのファイルハンドルを閉じることができます。
将来これを防ぐための2つのソリューションがあります。
Tomcatアプリからの出力が
catalina.outに入ることを許可しないでください。代わりにswallowOutputプロパティを使用し、出力用のログチャネルを構成します。 log4jによって管理されるログは、Catalinaプロセスを再起動せずにローテーションできます。単に
catalina.outにリダイレクトする代わりに、catalina.shを変更して、出力を cronolog にパイプします。そのようにして、cronologはログをローテーションします。
最良の解決策は「エコー」を使用することです（@ejoncasの提案として）：
$ echo '' > huge_file.log
この操作は非常に安全で高速です（1秒あたり約1Gのデータを削除します）。特に運用サーバーで操作している場合はそうです。
「rm」を使用してこのファイルを単純に削除しないでください。最初に書き込みプロセスを停止する必要があります。そうしないと、ディスクが解放されません。
参照： http://siwei.me/blog/posts/how-to-deal-with-huge-log-file-in-production
何かがまだ開いている場合、ファイルは実際には消えません。ログファイルを閉じて再び開くには、おそらくカタリナに信号を送る必要があります。
ファイルへの2番目のハードリンクがある場合、それも削除されるまで削除されません。
コマンドを入力して、どの削除済みファイルがメモリを占有しているかを確認します
$ Sudo lsof | grep deleted
まだメモリを保持している削除されたファイルが表示されます。
次に、pidまたはnameでプロセスを強制終了します
$ Sudo kill <pid>
$ df -h
今、あなたは同じメモリを持っていることを確認してください
メモリを占有しているファイルを確認するために以下のコマンドを入力しない場合
# cd /
# du --threshold=(SIZE)
どのファイルがしきい値サイズを超えて占有しているかを示す任意のサイズに言及し、ファイルを削除します