(mikegrb の回答を編集するつもりでしたが、少しやりすぎたと判断しました)
CLOSE_WAIT の意味はほぼ正確です。カーネルは、エントリを削除する前に、ローカル プロセスがファイル記述子を閉じるのを待っています。 TCP 接続は完全に切断されており、遠端は接続が終了したと認識している可能性がありますが、こちら側は問題を抱えています。
唯一の懸念事項は、多くの CLOSE_WAIT エントリがカーネル メモリとファイル記述子テーブル エントリを消費することです。これは、エントリが大量にある場合に問題になる可能性があります。表示されているエントリが一時的なものである場合は、おそらく ロット を循環しているだけです。 接続が閉じられてからプロセスがファイル記述子を閉じるまでのわずかな時間に、それらのごく一部が見られます。一方、それらが永続的である場合 (ポートと IP アドレスは時間の経過とともに変更されません)、何かが記述子をリークしており、それらが終了したときに fds を常に閉じるように修正する必要があります。 mikegrb が言ったように、新しいバージョンではすでに問題が修正されている可能性があるため、関連するメーリング リストで質問するか、変更ログを調べる必要があります。
CLOSE_WAIT 状態は、相手側が接続を閉じるために FIN セグメントを送信したことを意味します。接続はまだ確立されています。これは、半二重と考えることができるモードであり、この端からの接続を閉じる前に、データの最後のビットを端に送信して接続を閉じるように要求し、この端からバッファをフラッシュできるようにします。
多くの接続が CLOSE_WAIT にとどまっている場合は、CLOSE_WAIT に入った後、責任のあるプロセスがソケットを閉じていないことを意味します。 tcpdump またはその他のネットワーク トラフィック キャプチャ ツールを使用して、パケットを調べることができます。
また、担当するプロセスを見てください。好奇心から、責任あるプロセスは何ですか?修正された新しいバージョンが利用可能になるか、バグ レポートを提出する時期が来るかもしれません;)