Linuxサーバーのスペース不足

2回の連続したインタビューでこの質問をされましたが、さまざまなシステム管理者との調査と確認の後、良い答えが得られませんでした。誰かがここで私を助けることができるかどうか疑問に思っています。

サーバーのディスク容量が不足しています。非常に大きなログファイルに気付き、削除しても安全であると判断します。ファイルを削除しますが、ディスクはまだいっぱいであることを示しています。何が原因で、どのように修正しますか？そして、どのプロセスがこの巨大なログファイルを書き込んでいるかをどのように見つけますか？

これは一般的なインタビューの質問であり、さまざまな実稼働環境で発生する状況です。

ファイルのディレクトリエントリは削除されましたが、ロギングプロセスはまだ実行中です。すべてのファイルハンドルが閉じられ（プロセスが強制終了されたなど）、すべてのディレクトリエントリが削除されるまで、オペレーティングシステムによってスペースが再利用されることはありません。ファイルに書き込むプロセスを見つけるには、lsofコマンドを使用する必要があります。

質問の他の部分は、「プロセスを強制終了せずに、書き込み中のファイルをどのようにクリアするのか」ということもあります。理想的には、ファイルを削除するのではなく、ログファイルを「ゼロ」または「切り捨て」のようなものにしたいでしょう: > /var/log/logfile。

ファイルへの別のリンク（ハードリンクまたは開いているファイルハンドル）がまだあります。ファイルを削除すると、ディレクトリエントリのみが削除されます。ファイルデータとiノードは、最後の参照が削除されるまでハングアップします。

サービスが一時ファイルを作成し、ファイルを開いたままですぐに削除することは、やや一般的な方法です。これにより、ディスク上にファイルが作成されますが、プロセスが異常終了した場合にファイルが削除されることが保証され、他のプロセスが誤ってファイルを踏みつけないようにします。MySQLは、たとえば、ディスク上のすべての一時テーブルに対してこれを行います。マルウェアは、多くの場合、同様の手法を使用してファイルを隠します。

Linuxでは、これらの削除されたファイルにとして簡単にアクセスできます/proc/<pid>/fd/<filenumber>。

私はシステム管理者ではありませんが、Unix.SEで収集したものから、Linuxシステムは、それらを指すすべてのファイル記述子が持つまでリンクが解除された後、ファイルを実際に削除しません（空き/再利用可能としてマークします）閉じられました。したがって、最初の部分に答えるために、プロセスがまだそれを読んでいるので、スペースはまだ無料ではありません。2番目に答えるために、どのプロセスがファイルを使用しているかを確認できますlsof。

明らかなハードリンク/オープンファイルの答えに加えて、1つの代替答え：そのファイルは、/var/log/lastlog実際にはそれほど多くのスペースを占有していないRHEL などの（非常に）疎なファイルです。削除してもほとんど影響がないため、次に大きいファイルを調べる必要があります。

ファイルを書き込むプロセスがルートの場合、スーパーユーザーの予約済みファイルスペースに書き込みます。ファイルシステムには、ユーザータスクがディスクをいっぱいにした場合にシステムを動作させ続けるためのスペースがあります。このスペース（デフォルトでは5％）は、多くのツールからは見えません。

lsofは、どのプロセスがファイルをロックしたか、ergoがファイルに書き込んでいるかを表示できます。

ファイルがプロセスによって開かれていることに加えて、2番目のケースは、btrfsまたはなどのスナップショットをサポートするファイルシステムがある場合ですZFS。

たとえば、その巨大なログファイルが存在するスナップショットを作成します。ここでファイルを削除すると、デルタのみが削除されます。また、ファイルが使用されていない場合にのみ、デルタが削除されます。

こちらもご覧ください：

• https://superuser.com/questions/863588/how-to-delete-a-file-in-all-snapshots-on-a-btrfs-system

• ZFS：スナップショットからファイルを削除しますか？

3番目のケースは、ブロックレベルの重複排除をサポートするファイルシステムがあり、ほとんどのファイルが別のファイルと同一である場合です。ログの内容が同一になるように、同じFSを共有するsyslogコンテナまたはVMにログを送信しているコンテナまたはVMがない限り、ログでこれが発生することはありません。