Я запускаю Netcat на сервере Ubuntu 18.04.3 LTS для прослушивания порта 469. Этот сервер получает частые TCP-запросы от других машин на порт 469, который я использую для мониторинга работоспособности сервера. Я запускаю Netcat с помощью:
nc -kl 469
и я вижу, что процесс идет:
$ ps -aux | grep 469что дает следующий результат:
корень 11041 0.0 0.1 13596 1060 ? S 31 авг 0:21 nc -kl 469`
Эта система работает хорошо около 24-28 часов, но затем Netcat перестает отвечать. После расследования я пришел к выводу, что проблема в том, что буфер Recv-Q "заполняется". Обычно буфер Recv-Q равен нулю до момента, когда Netcat перестает отвечать. После того, как он перестал отвечать, буфер Recv-Q становится постоянным 2 (вместо обычного 0). Я могу проверить это с помощью "ss" следующим образом.
$ ss -tnlи затем я вижу это, где виден аномальный Recv-Q 2.
$ ss -tnl
Состояние Прием-Q Отправка-Q Локальный адрес:Порт Адрес однорангового узла:Порт
СЛУШАТЬ 0 128 0.0.0.0:22 0.0.0.0:*
СЛУШАТЬ 0 64 0.0.0.0:42587 0.0.0.0:*
СЛУШАТЬ 0 128 0.0.0.0:46663 0.0.0.0:*
СЛУШАТЬ 0 128 0.0.0.0:111 0.0.0.0:*
СЛУШАТЬ 2 1 0.0.0.0:469 0.0.0.0:*
СЛУШАТЬ 0 128 127.0.0.53%lo:53 0.0.0.0:*
СЛУШАТЬ 0 128 [::]:22 [::]:*
СЛУШАТЬ 0 64 [::]:44057 [::]:*
СЛУШАТЬ 0 128 [::]:55085 [::]:*
СЛУШАТЬ 0 128 [::]:111 [::]:*
У нас есть несколько других серверов Ubuntu, которые также запускают Netcat, прослушивая порт 469, точно так же. Они НЕ выходят из строя - они работают уже несколько недель. Но этот сервер выходит из строя снова и снова, даже после перезапуска, и всегда примерно через 24+ часа. Единственное отличие между этим и другими серверами (которые я могу вспомнить) заключается в том, что на этом сервере также смонтирован том nfs (как видно из прослушивания порта 111 выше).
Что может быть причиной этого? Можно ли как-то очистить Recv-Q (из bash), чтобы я мог очищать его с определенным интервалом (как временное решение)? Любая помощь будет высоко оценена.
решение1
Теперь я нашел ответ на этот вопрос и хочу опубликовать его здесь, вдруг он кому-то еще поможет.
Проблема была в том, что на сервере также был установлен Strongswan, и входящие TCP-запросы на порт 469 приходили через соединение IPSec с другого сервера. Случалось, что соединение IPSEC иногда прерывалось на очень короткое время, когда соединение IPSec переустанавливалось (примерно каждые 24 часа). Если это происходило прямо посреди текущего TCP Syn/Ack на порт 469, это оставляло его в подвешенном состоянии. И поэтому "nc -kl" застревал с пакетами в буфере Recv-Q.
Решением было настроить Strongswan так, чтобы повторная синхронизация происходила без прерывания. Урок состоял в том, что вместо того, чтобы искать проблему с буфером Recv-Q или Netcat, необходимо было понять первопричину, которая в данном случае заключалась в понимании того, почему TCP Syn/Ack не мог завершиться.