(Chystal jsem se upravit mikegrbovu odpověď, ale rozhodl jsem se, že jsem ji příliš zmasakroval)
CLOSE_WAIT znamená v podstatě přesně to, co říká – jádro čeká, až místní proces zavře svůj deskriptor souboru, než odstraní záznam. TCP spojení bylo zcela přerušeno a vzdálený konec může mít dojem, že spojení je konečné, ale váš konec drží věci.
Jediným problémem je, že mnoho položek CLOSE_WAIT spotřebovává paměť jádra a položky tabulky deskriptorů souborů, což může být problém, pokud je jich velké množství. Pokud jsou položky, na které se díváte, přechodné, pak je to pravděpodobně jen tím, že hodně projíždíte na kole TCP spojení a vidíte malý zlomek z nich v malém množství času mezi uzavřením spojení a procesem, kdy se zavře deskriptor souboru. Na druhou stranu, pokud jsou trvalé (porty a IP adresy se v průběhu času nemění), pak něco uniká deskriptorům a je třeba to opravit, aby to vždy zavřelo své fds, když to s nimi skončí. Jak řekl mikegrb, novější verze již možná problém vyřešila, takže otázka na příslušný mailing list nebo zkoumání changelogů je pravděpodobně oprávněná.
Stav CLOSE_WAIT znamená, že druhý konec odeslal segment FIN k uzavření spojení. Spojení je stále navázáno. Je v režimu, který byste si mohli představit jako poloviční duplex, který umožňuje tomuto konci vyprázdnit všechny vyrovnávací paměti a odesílat poslední bity dat na konec, který požaduje uzavření spojení před uzavřením spojení z tohoto konce.
Pokud máte mnoho připojení, která zůstávají v CLOSE_WAIT, znamená to, že odpovědný proces neuzavírá soket, jakmile přejde do CLOSE_WAIT. K prohlížení paketů můžete použít tcpdump nebo jiné nástroje pro zachycení síťového provozu.
Podívejte se také na odpovědný proces. Ze zvědavosti, jaký je odpovědný proces? Možná je k dispozici novější opravená verze nebo možná je čas podat hlášení o chybě;)