По документации сказано что состояние CLOSE_WAIT ожидает закрытия сокета со стороны приложения, однако получаетя так, что это состояние висит у уже закрытого сокета (проверялось lsof и netstat). Ядро: Linux l 2.6.37.6-0.7-desktop #1 SMP PREEMPT 2011-07-21 02:17:24 +0200 x86_64 x86_64 x86_64 GNU/Linux Висит довольно долго, потом само отваливается. При этом к приложению невозможно подконнектиться по порту где возникает проблема с CLOSE_WAIT, а по другим портам нормально. Когда рассасывается начинает коннектиться и по этому порту. Соответственно вопросы: 1. Это нормальное поведение или CLOSE_WAIT у закрытого приложением сокета это бага? 2. Как можно убить такие безпроцессные сокеты на свежих ядрах? Гугление затрудняется просто ворохом копипаста из документации что это ожидание закрытия от приложения или какоето шаманство с tcp_conn_track которого у меня впринципе нету и подобное. 3. Можно ли поменять таймаут с которым висит CLOSE_WAIT? Просмотр /proc/sys пока не нашел ничего похожего.
Глянь сюда : OpenNET: статья - как избежать CLOSE_WAIT (socket) http://www.opennet.ru/base/dev/reuses.txt.html И можешь спросить там на форуме.
http://www.opennet.ru/base/dev/reuses.txt.html >> "Hа действительно закрытом сокете, естественно, при правильной ядреной реализации, этого состояния быть не должно." Тоесть ответ на п1 - бага. На это очень похоже т.к. происходить стало при апгрейде opensuse до 11.4, но как локализовать из-за чего это происходит чтобы отрепортить непонятно. Ответ на остальные вопросы все еще актуален. Насчет У.Р. Стивенс http://www.ozon.ru/context/detail/id/1018962/ - самое свежее 2007 год. За это время /proc/sys мог поменяться до неузнаваемости, ядрышки пекутся как на дрожжах, я не первый раз с этим сталкиваюсь, если там и рассматриваются такие действителньо низкоуровневые вещи, то скорее всего в контексте уже устаревшего ядра, тут нужна информация посвежее. Я и более свежие посты нахожу с устаревшими рецептами (или изначально нерабочими), что и затрудняет сильно поиск. Например постил ошибку что не работает netstat -M - как раз писал что не может прочитать такой то файл в /proc, я поискал и оказалось файл поменял расположение(возможно и формат), как ответили в баге - это netfilter artifact. Кстати не исправили до сих пор, netstat так и стучится в устаревший ip_masquerade вместо ip_conntrack. Даже конкуренты уже появились в виде netstat-nat
