Потерянные соединения в состоянии CLOSE_WAIT

У меня есть машина SLES, которая накапливает TCP-соединения в состоянии CLOSE_WAIT для того, что кажется навсегда. Эти дескрипторы в итоге высасывают всю доступную память. На данный момент у меня 3037 из них, но это было намного выше, до недавней перезагрузки.

Интересно то, что они не из соединений с локальными портами, которые я ожидаю прослушивания. У них нет связанных PID, и их таймеры, похоже, истекли.

# netstat -ton | grep CLOSE_WAIT
tcp      176      0 10.0.0.60:54882     10.0.0.12:31663      CLOSE_WAIT  off (0.00/0/0)
tcp       54      0 10.0.0.60:60957     10.0.0.12:4503       CLOSE_WAIT  off (0.00/0/0)
tcp       89      0 10.0.0.60:50959     10.0.0.12:3518       CLOSE_WAIT  off (0.00/0/0)

# netstat -tonp | grep CLOSE_WAIT
tcp       89      0 10.0.0.59:45598     10.0.0.12:1998       CLOSE_WAIT  -                   
tcp       15      0 10.0.0.59:60861     10.0.0.12:1938       CLOSE_WAIT  -                   
tcp        5      0 10.0.0.59:56173     10.0.0.12:1700       CLOSE_WAIT  -     

Я не черный пояс, когда дело доходит до стека TCP или сетей ядра, но конфигурация TCP кажется разумной, так как эти значения являются значениями по умолчанию для man-страницы:

# cat /proc/sys/net/ipv4/tcp_fin_timeout 
60
# cat /proc/sys/net/ipv4/tcp_keepalive_time 
7200

Так что же дает? Если таймеры истекли, не должен ли стек автоматически очистить это? Я эффективно даю себе долгосрочную DoS, поскольку эти вещи накапливаются.

Нет, тайм-аут для CLOSE_WAIT. Я думаю, что это offзначит , что означает в вашей продукции.

Чтобы выйти CLOSE_WAIT, приложение должно закрыть сокет явно (или выйти).

Смотрите Как сломать CLOSE_WAIT .

Если netstatотображается -в столбце процесса:

• вы работаете с соответствующими привилегиями и возможностями (например, от имени root)?
• они могут быть процессами ядра (например, nfsd)

CLOSE_WAITуказывает, что клиент закрывает соединение, но приложение еще не закрыло его, или клиент не закрывает. Вы должны определить, какая программа или программы имеют эту проблему. Попробуйте использовать, netstat -tonp 2>&1 | grep CLOSEчтобы определить, какие программы удерживают соединения.

Если в списке нет программ, то служба предоставляется ядром. Вероятно, это службы RPC, такие как nfsили rpc.lockd. Прослушивающие службы ядра могут быть перечислены с netstat -lntp 2>&1 | grep -- -.

Если службы RPC не были привязаны к фиксированным портам, они будут привязаны к временным портам, как показывают ваши соединения. Вы также можете проверить процессы и монтирования на другом сервере.

Вы можете связать свои службы NFS с фиксированными портами, выполнив следующие действия:

1. Выберите четыре неиспользуемых порта для NFS (здесь используется 32763-32766)
2. Добавить фиксированные порты для NFS в /etc/services

   rpc.statd-bc 32763 / udp # RCP statd трансляция
   rpc.statd-bc 32763 / tcp
   rpc.statd 32764 / udp # RCP statd listen
   rpc.statd 32764 / tcp
   rpc.mountd 32765 / udp # RPC mountd
   rpc.mountd 32765 / tcp
   rpc.lockd 32766 / udp # RPC lockd / nlockmgr
   rpc.lockd 32766 / tcp

3. Настройте statd для использования параметров --port 32763 --outgoing-port 32764
4. Настройте rpcmountd для использования опции --port 32765
5. Завершите работу и перезапустите службы NFS и RPC.