Ich führe Netcat auf einem Ubuntu 18.04.3 LTS-Server aus, um Port 469 abzuhören. Dieser Server erhält häufig TCP-Anfragen von anderen Maschinen an Port 469, den ich verwende, um die Verfügbarkeit des Servers zu überwachen. Ich starte Netcat mit:
nc -kl 469
und ich kann sehen, dass der Prozess live ist mit:
$ ps -aux | grep 469was zu dieser Ausgabe führt:
Wurzel 11041 0,0 0,1 13596 1060 ? S Aug31 0:21 nc -kl 469`
Dieses System funktioniert etwa 24 bis 28 Stunden lang einwandfrei, aber dann reagiert Netcat nicht mehr. Nach einer Untersuchung glaube ich, dass das Problem darin liegt, dass der Recv-Q-Puffer „voll“ ist. Normalerweise ist der Recv-Q-Puffer bis zu dem Punkt, an dem Netcat nicht mehr reagiert, null. Nachdem er nicht mehr reagiert hat, ist der Recv-Q-Puffer konstant 2 (anstelle der normalen 0). Ich kann dies mit „ss“ wie folgt überprüfen.
$ ss -tnlund dann sehe ich das hier, wo der abnormale Recv-Q von 2 sichtbar ist.
$ ss -tnl
Status Recv-Q Send-Q Lokale Adresse:Port Peer-Adresse:Port
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 64 0.0.0.0:42587 0.0.0.0:*
LISTEN 0 128 0.0.0.0:46663 0.0.0.0:*
LISTEN 0 128 0.0.0.0:111 0.0.0.0:*
LISTEN 2 1 0.0.0.0:469 0.0.0.0:*
LISTEN 0 128 127.0.0.53%lo:53 0.0.0.0:*
LISTEN 0 128 [::]:22 [::]:*
LISTEN 0 64 [::]:44057 [::]:*
LISTEN 0 128 [::]:55085 [::]:*
LISTEN 0 128 [::]:111 [::]:*
Wir haben mehrere andere Ubuntu-Server, die Netcat ebenfalls auf Port 469 laufen lassen, und zwar auf genau dieselbe Weise. Sie fallen NICHT aus – sie sind seit Wochen aktiv. Aber dieser Server fällt immer wieder aus, sogar nach einem Neustart und immer nach über 24 Stunden. Der einzige Unterschied zwischen diesem und den anderen Servern (der mir einfällt) besteht darin, dass dieser Server auch ein gemountetes NFS-Volume hat (wie man an der Überwachung von Port 111 oben sehen kann).
Was könnte die Ursache dafür sein? Kann ich Recv-Q irgendwie löschen (von Bash), sodass ich es in regelmäßigen Abständen löschen kann (als vorübergehende Lösung)? Jede Hilfe ist sehr willkommen.
Antwort1
Ich habe jetzt die Antwort auf diese Frage gefunden und wollte sie hier posten, nur für den Fall, dass sie jemand anderem helfen kann.
Das Problem bestand darin, dass auf dem Server auch Strongswan installiert war und die eingehenden TCP-Anfragen an Port 469 über eine IPSec-Verbindung von einem anderen Server kamen. Was passierte, war, dass die IPSEC-Verbindung manchmal für sehr kurze Zeit unterbrochen wurde, wenn die IPSec-Verbindung neu verschlüsselt wurde (etwa alle 24 Stunden). Wenn das mitten in einem laufenden TCP Syn/Ack an Port 469 passierte, blieb es in der Schwebe. Und so blieb „nc -kl“ mit Paketen im Recv-Q-Puffer hängen.
Die Lösung bestand darin, Strongswan so zu konfigurieren, dass die Neuverschlüsselung ohne Unterbrechung erfolgte. Die Erkenntnis war, dass es nicht notwendig war, nach einem Problem mit dem Recv-Q-Puffer oder Netcat zu suchen, sondern die Grundursache zu verstehen – in diesem Fall, herauszufinden, warum TCP Syn/Ack nicht abgeschlossen werden konnte.