Re: Apache und FIN_WAIT_2

Oliver Fromme schrieb:
> Moin,
>
> Es hat sonst niemand geantwortet, daher versuche ich mal
> mein Glück ...
>
> Philon Terving <philon(at)macnews.de> wrote:
> > ich habe hier nach wie vor einen Webserver mit 4.11 in Betrieb.
>
> Ich würde empfehlen, eine Aktualisierung auf 6.1 oder
> RELENG_6 in Betracht zu ziehen.

ja, das tue ich auch... wenn der lang ersehnte Hardwaretausch
stattfindet wird das Setup auf die 6 umgesetzt.

>
> > Dieser hat doch wirklich die Angewohnheit eine ganze Menge
> > Verbindungen des Apachen offen zu halten (o.g. FIN_WAIT_2).
>
> Was heißt »eine ganze Menge«? Sind es so viele, daß es ein
> konkretes Problem verursacht, oder stört Dich nur die lange
> Ausgabe von »netstat -an«?

es schwankt zwischen 100-150, das verwunderte mich einfach. Ab und an
verliert der Apache-Mutterprozess auch seine Kinder und meldet dann
"Long lost child came home". Ich überlegte ob das damit in Zusammenhang
zu bringen sei.

>
> Daß eine größere Anzahl Verbindungen in dem Zustand landen,
> ist durchaus nicht ungewöhnlich. Auf einem Webserver hier
> sieht die Verteilung der Zustände gerade so aus:
>
> $ netstat -an | awk '/tcp/{print $NF}' | sucs
> 1 CLOSE_WAIT
> 5 LAST_ACK
> 10 FIN_WAIT_1
> 18 ESTABLISHED
> 22 LISTEN
> 33 TIME_WAIT
> 152 FIN_WAIT_2

das beruhigt mich zumindest.

> ("sucs" ist bei mir ein Alias für "sort | uniq -c | sort -n".)

und da hab ich schon wieder einen guten Trick gelernt :)

> Wie Du siehst, sind mit Abstand die meisten in FIN_WAIT_2.
> Das kann aber auch über den Tag schwanken; manchmal sind
> die Verbindungen im TIME_WAIT in der Überzahl. Stellt aber
> alles normalerweise kein Problem dar.
>
> Verbindungen in FIN_WAIT_2 sind »halb geschlossen«, d.h.
> die lokale Seite ist geschlossen (und dies wurde auch vom
> Partner bestätigt), und es wird auf den FIN vom Partner
> gewartet (oder ein RST). Bis das passiert, können noch
> Daten empfangen, aber nicht mehr gesendet werden.

soviel hatte ich auch ergooglet. Es blieb nur die Frage ob der FIN vom
Partner nicht kommt oder obs an mir liegt. Ein tcpdump wird mir darüber
vielleicht noch Aufschluss geben können.

>
> > Zusammenfassend jedoch:
> > - FIN_WAIT_2 wartet wohl auf ein abschließendes Wort um die Verbindung
> > zum Client korrekt zu beenden
> > - dieses FIN_WAIT_2 kann aus unterschiedlichen Gründen unbeantwortet bleiben
> > - zum einen wäre da die Firewall des Rechners (stateful mit keep-alive
> > für eingehenden HTTP)
>
> Denkbar, wenn sie nicht richtig konfiguriert ist.

das Problem ist, dass dieser Rechner eigentlich längere Zeit ohne Update
rumdümpelt, da im fernen RZ positioniert. Ein SSH-Update 4-5-6 hatten
wir hier auch mal kurzfristig diskutiert, insgesamt ist mir die Sache
aber eher zu heiss. Der Hardwarewechsel kommt da schon ganz recht.

IPFW2 im 4.11er Kernel manuell zu aktivieren, bereitete sowieso einige
Umstände. Das Firewallset ist damit auch eher zurückhaltend eingestellt.

> FreeBSD hat einen Timeout von 10 Minuten (tcp_maxidle).
> Wenn sich also nach dem Empfang des FIN+ACK-Packets 10 Mi-
> nuten lang gar nichts tut, wird die Verbindung gelöscht.

ich hatte die Ausgabe von netstat immer wieder beobachtet und mir kam es
vor als würden über Wochen hinweg immer die selben Hosts "hängen". Aber
wenn der maxidle ja tut wie er soll, sollte das ja nicht möglich sein.

> > Anscheinend hilft das simple Beenden des HTTPd nicht viel!?
>
> Richtig. Der TCP/IP-Stack sorgt auch dann für ein korrek-
> tes Beenden der Verbindung, wenn der Prozeß, dem der Socket
> gehörte, nicht mehr existiert.

hm, ich werde die Geschehnisse weiter im Auge behalten müssen. Soweit
danke ich Dir vielmals für die umfangreichen Erläuterungen. :)

Philon

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 21 Apr 2006 - 00:32:54 CEST