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