Сокеты в CLOSE_WAIT не принадлежащие ни одному процессу

Тема в разделе "WASM.UNIX", создана пользователем semen, 15 дек 2011.

  1. semen

    semen New Member

    Публикаций:
    0
    Регистрация:
    8 июн 2004
    Сообщения:
    334
    Адрес:
    Russia
    По документации сказано что состояние 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 пока не нашел ничего похожего.
     
  2. valterg

    valterg Active Member

    Публикаций:
    0
    Регистрация:
    19 авг 2004
    Сообщения:
    2.105
    Глянь сюда :
    OpenNET: статья - как избежать CLOSE_WAIT (socket)
    http://www.opennet.ru/base/dev/reuses.txt.html

    И можешь спросить там на форуме.
     
  3. wsd

    wsd New Member

    Публикаций:
    0
    Регистрация:
    8 авг 2007
    Сообщения:
    2.824
    valterg
    лучше и наглядней первоисточник - У.Р. Стивенс
     
  4. semen

    semen New Member

    Публикаций:
    0
    Регистрация:
    8 июн 2004
    Сообщения:
    334
    Адрес:
    Russia
    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 :)