Frage Sehr viele TIME_WAIT-Verbindungen sagen Netstat


Okay, das schleicht mich aus - ich sehe etwa 1500-2500 davon:

root@wherever:# netstat

Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 localhost:60930         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60934         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60941         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60947         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60962         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60969         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60998         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60802         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60823         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60876         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60886         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60898         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60897         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60905         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60918         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60921         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60673         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60680         localhost:sunrpc        TIME_WAIT  
[etc...]

root@wherever:# netstat | grep 'TIME_WAIT' |wc -l
1942

Diese Zahl ändert sich schnell.

Ich habe eine ziemlich enge Iptables-Konfiguration, also habe ich keine Ahnung, was das verursachen kann. irgendwelche Ideen?

Vielen Dank,

Tamas

Bearbeiten: Ausgabe von 'netstat -anp':

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:60968         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60972         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60976         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60981         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60980         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60983         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60999         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60809         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60834         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60872         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60896         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60919         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60710         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60745         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60765         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60772         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60558         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60564         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60600         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60624         127.0.0.1:111           TIME_WAIT   -               

24
2018-06-10 14:35


Ursprung


Haben Sie etwas, das NFS auf dem gleichen Computer installiert hat, der es exportiert? - Paul Tomblin
@ Paul Tomblin: Nein. - KTamas
Bitte geben Sie die Ausgabe von "netstat -anp" an (relevante Teile sind ausreichend). Es zeigt Ihnen, welche Ports von welchen Anwendungen verwendet werden. - cstamas
@cstamas: fertig. - KTamas
Nun, Sie sollten sich die etablierten Verbindungen anschauen, um herauszufinden, welches Programm es ist. "rcpinfo -p" kann auch helfen herauszufinden, was mit Portmapper kommuniziert. - cstamas


Antworten:


Wie von anderen erwähnt, einige Verbindungen in TIME_WAIT ist ein normaler Teil der TCP-Verbindung. Sie können das Intervall sehen, indem Sie untersuchen /proc/sys/net/ipv4/tcp_fin_timeout:

[root@host ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60

Und ändere es, indem du diesen Wert änderst:

[root@dev admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

Oder permanent durch Hinzufügen zu /etc/sysctl.conf

net.ipv4.tcp_fin_timeout=30

Wenn Sie den RPC-Dienst oder das NFS nicht verwenden, können Sie es einfach deaktivieren:

/etc/init.d/nfsd stop

Und schalte es komplett aus

chkconfig nfsd off

16
2018-06-10 17:51



Ja, mein ipconfig-Skript senkt es bereits auf 30. Ich habe nfsd nicht in /etc/init.d/, aber ich habe Portmap ausgeführt, habe es gestoppt, jetzt werden TIME_WAITs auf ein paar Instanzen (1-5) reduziert. Vielen Dank. - KTamas
Uhh, tcp_fin_timeout hat nichts mit Sockets im time_wait Zustand zu tun. Das betrifft fin_wait_2. - diq
+1 für diqs Kommentar. Sie sind nicht verwandt. - mcauth


TIME_WAIT ist normal. Es ist ein Zustand nach dem Schließen eines Sockets, der vom Kernel verwendet wird, um Pakete zu verfolgen, die verloren gegangen sind und spät zur Party aufgetaucht sind. Eine hohe Anzahl von TIME_WAIT-Verbindungen ist ein Symptom für das Erhalten vieler kurzlebiger Verbindungen, nicht um nichts zu kümmern.


13
2018-06-10 14:47





Etwas auf Ihrem System führt viele RPC (Remote Procedure Calls) innerhalb Ihres Systems durch (beachten Sie, dass sowohl Quelle als auch Ziel localhost ist). Dies wird häufig für locked für NFS-Mounts gesehen, aber Sie können es auch für andere RPC-Aufrufe wie rpc.statd oder rpc.spray sehen.

Sie könnten versuchen, "lsof -i" zu verwenden, um zu sehen, wer diese Sockets geöffnet hat und sehen, was es macht. Es ist wahrscheinlich harmlos.


4
2018-06-10 14:42



Nichts Ungewöhnliches dort, ich sehe ein TCP *: sunrp (LISTEN) für portmap aber rate das ist normal. - KTamas
Machen Sie es so oft, bis Sie sehen, wer die Verbindung öffnet. - Paul Tomblin
netstat -epn --tcp zeigt Ihnen dieselben Informationen an. Sofern Sie NFS nicht verwenden, haben Sie wahrscheinlich sehr wenig Grund für die Verwendung von Portmap. Du könntest es entfernen. - David Pashley
Ich benutze zwar nicht NFS, aber apt-get remove portmap möchte 'fam' entfernen, was automatisch von libfam0 installiert wurde, welches von courier-imap installiert wurde. apt-cache sagt 'fam' ist ein empfohlenes Paket für libfam0. - KTamas


Es ist nicht wichtig. Das bedeutet, dass Sie viele Sun RCP TCP-Verbindungen öffnen und schließen (1500-2500 davon alle 2-4 Minuten). Das TIME_WAIT Zustand ist, was ein Socket beim Schließen passiert, um zu verhindern, dass Nachrichten für die falschen Anwendungen eintreffen, wie es der Fall wäre, wenn der Socket zu schnell wiederverwendet würde, und für einige andere nützliche Zwecke. Mach dir keine Sorgen darüber.

(Es sei denn natürlich, Sie führen nicht wirklich etwas aus, das so viele RCP-Operationen verarbeiten sollte. Dann machen Sie sich Sorgen.)


3
2018-06-10 14:40



Ich betreibe meistens Kurier-Imap und Postfix. - KTamas


Ich hatte das gleiche Problem. Ich kostete mich mehrere Stunden, um herauszufinden, was vor sich geht. In meinem Fall war der Grund dafür, dass Netstat versucht, den Hostnamen zu suchen, der der IP entspricht (ich nehme an, dass er die gethostbyaddr API verwendet). Ich benutzte eine eingebettete Linux-Installation, die keine /etc/nsswitch.conf hatte. Zu meiner Überraschung existiert das Problem nur, wenn Sie tatsächlich einen netstat -a ausführen (dies wurde durch Ausführen von portmap im ausführlichen und im Debug-Modus festgestellt).

Was passierte, war folgendes: Standardmäßig versuchen die Suchfunktionen auch, den ypbind-Daemon (Sun Yellow Pages, auch bekannt als NIS) zu kontaktieren, um einen Hostnamen abzufragen. Um diesen Dienst abzufragen, muss die portmapper portmap kontaktiert werden, um den Port für diesen Dienst zu erhalten. Jetzt wurde der Portmapper in meinem Fall über TCP kontaktiert. Der Portmapper teilt der libc-Funktion mit, dass kein solcher Dienst existiert und die TCP-Verbindung geschlossen wird. Wie wir wissen, geben geschlossene TCP-Verbindungen für einige Zeit den Status TIME_WAIT ein. So fängt Netstat diese Verbindung beim Auflisten ab und diese neue Zeile mit einer neuen IP gibt eine neue Anfrage aus, die eine neue Verbindung im TIME_WAIT Zustand erzeugt und so weiter ...

Um dieses Problem zu lösen, erstellen Sie eine Datei /etc/nsswitch.conf, die nicht die RPC-NIS-Dienste verwendet, d. H. Mit den folgenden Inhalten:

passwd:         files
group:          files
hosts:          files dns
networks:       files dns
services:       files
protocols:      files
netmasks:       files

0
2018-01-14 17:25