Какие распространенные ошибки программирования могут вызывать зависание CLOSE_WAIT в режиме запуска по краю epoll?
Мне интересно, какие распространенные программные ситуации / ошибки могут вызывать серверный процесс, который я ввел в CLOSE_WAIT, но не закрывал сокет.
То, что я хочу сделать, это вызвать эту ситуацию, чтобы я мог ее исправить. В обычной среде разработки я не смог его запустить, но тот же код, который используется на живом сервере, иногда получает их, так что через много дней у нас их сотни.
Поиск в Google для close_wait, и, похоже, это очень распространенная проблема, даже в зрелых и предположительно хорошо написанных сервисах, таких как nginx.
Решение
CLOSE_WAIT в основном, когда удаленный конец выключил сокет, но локальное приложение еще не вызвало close() в теме. Обычно это происходит, когда вы не ожидая чтения данных из сокета и, следовательно, не следите за читаемостью.
Многие приложения для удобства всегда отслеживают сокет для удобства чтения, чтобы обнаружить закрытие.
Сценарий, чтобы попробовать это:
- Пир посылает 2к данных и сразу закрывает данные
- Ваш сокет затем регистрируется в epoll и получает уведомление для удобства чтения.
- Ваше приложение читает только 1 КБ данных
- Вы прекращаете мониторинг сокета для удобства чтения
- (Я не уверен, что эполл, инициируемый ребром, в конечном итоге доставит событие отключения как отдельное событие).
Смотрите также:
(от man epoll_ctl)
EPOLLRDHUP (начиная с Linux 2.6.17)
Потоковое сокет однорангового соединения закрыто или завершено запись половины соединения. (Этот флаг особенно полезен для записи
простой код
обнаружить отключение однорангового узла при использовании мониторинга Edge Triggered.)
Другие решения