Re: Apache und FIN_WAIT_2

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.

> 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«?

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

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

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.

> 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.

> - zum anderen aussterbende Clients (will sagen, Modems welche die
> Verbindung kappen etc.)

Hm. Heutzutage sind nicht mehr allzuviele Leute per Modem
unterwegs, oder? Außerdem ist es doch eher unwahrschein-
lich, daß just in dem Moment die Verbindung gekappt wird.

> Nun bleibt mir letztendlich der schale Beigeschmack von Aussagen wie,
> dass solche Verbindungen irgendwann den Rechner füllen und ggf. den
> Kernel/das System killen. Allerdings soll wohl laut RFC kein Timeout
> vergeben sein. Apache-Doku verweist allerdings darauf, trotzdem einen zu
> setzen (seit FreeBSD2.0 angeblich möglich!?).

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.

> Wie ist damit zu Verfahren?

In der Praxis tritt nach meiner Erfahrung eigentlich kein
Problem damit auf. Wenn es bei Dir ein Problem verursacht,
dann muß irgendwo etwas im Argen liegen bzw. verbesserungs-
würdig sein. Vielleicht stimmt z.B. mit der Paketfilter-
Konfiguration etwas nicht.

> 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.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
I suggested holding a "Python Object Oriented Programming Seminar",
but the acronym was unpopular.
        -- Joseph Strout
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message