Checkout Tools
  • last updated 7 hours ago
Constraints: committers
Constraints: files
Constraints: dates

Changeset 81322 is being indexed.

Part 2 of the semi-regular HTML normalisation. Now on to

apache-site... No thirty.

  1. … 45 more files in changeset.
A truly mighty mod normalising HTML tags to uppercase, and

'i' and 'b' to 'EM' and 'STRONG' respectively. Been threatening

to do this for months.. no-one need try to maintain this when

writing/modifiying the docs.

  1. … 91 more files in changeset.

If SCO's going to break their links, I'm not going to go searching for where they

moved it to.

Cold and rainy and dark.

ml" -->

<H1 ALIGN="CENTER">Connections in the FIN_WAIT_2 state and Apache</H1>


<LI><H2>What is the FIN_WAIT_2 state?</H2>

Starting with the Apache 1.2 betas, people are reporting many more

connections in the FIN_WAIT_2 state (as reported by

<code>netstat</code>) than they saw using older versions. When the

server closes a TCP connection, it sends a packet with the FIN bit

sent to the client, which then responds with a packet with the ACK bit

set. The client then sends a packet with the FIN bit set to the

server, which responds with an ACK and the connection is closed. The

state that the connection is in during the period between when the

server gets the ACK from the client and the server gets the FIN from

the client is known as FIN_WAIT_2. See the <A

HREF="">TCP RFC</A> for the

technical details of the state transitions.<P>

The FIN_WAIT_2 state is somewhat unusual in that there is no timeout

defined in the standard for it. This means that on many operating

systems, a connection in the FIN_WAIT_2 state will stay around until

the system is rebooted. If the system does not have a timeout and

too many FIN_WAIT_2 connections build up, it can fill up the space

allocated for storing information about the connections and crash

the kernel. The connections in FIN_WAIT_2 do not tie up an httpd


<LI><H2>But why does it happen?</H2>

There are numerous reasons for it happening, some of them may not

yet be fully clear. What is known follows.<P>

<H3>Buggy clients and persistent connections</H3>

Several clients have a bug which pops up when dealing with

<A HREF="../keepalive.html">persistent connections</A> (aka keepalives).

When the connection is idle and the server closes the connection

(based on the <A HREF="../mod/core.html#keepalivetimeout">

KeepAliveTimeout</A>), the client is programmed so that the client does

not send back a FIN and ACK to the server. This means that the

connection stays in the FIN_WAIT_2 state until one of the following



<LI>The client opens a new connection to the same or a different

site, which causes it to fully close the older connection on

that socket.

<LI>The user exits the client, which on some (most?) clients

causes the OS to fully shutdown the connection.

<LI>The FIN_WAIT_2 times out, on servers that have a timeout

for this state.


If you are lucky, this means that the buggy client will fully close the

connection and release the resources on your server. However, there

are some cases where the socket is never fully closed, such as a dialup

client disconnecting from their provider before closing the client.

In addition, a client might sit idle for days without making another

connection, and thus may hold its end of the socket open for days

even though it has no further use for it.

<STRONG>This is a bug in the browser or in its operating system's

TCP implementation.</STRONG> <P>

The clients on which this problem has been verified to exist:<P>


<LI>Mozilla/3.01 (X11; I; FreeBSD 2.1.5-RELEASE i386)

<LI>Mozilla/2.02 (X11; I; FreeBSD 2.1.5-RELEASE i386)

<LI>Mozilla/3.01Gold (X11; I; SunOS 5.5 sun4m)

<LI>MSIE 3.01 on the Macintosh

<LI>MSIE 3.01 on Windows 95


This does not appear to be a problem on:


<LI>Mozilla/3.01 (Win95; I)



It is expected that many other clients have the same problem. What a

client <STRONG>should do</STRONG> is periodically check its open

socket(s) to see if they have been closed by the server, and close their

side of the connection if the server has closed. This check need /export/home/cvs/CVSROOT/cvsedit

Update the fin_wait_2 page to reflect the current understanding

of the issues; remove the suggestion that Apache is buggy, since

no bugs have been found in that code. It now appears most likely

that it is just the result of a bad interaction. The real solution,

as always, is still a timeout for FIN_WAIT_2.


Obtained from:

Submitted by:

Reviewed by:

Fix Squent typo.


Obtained from:

Submitted by:

Reviewed by:

More HTML cleanups, retrofit of intentional <XA> tag to a no-op

<A NAME> (thanks, Marc). Lots of trailing blanks removed throughout.

Small addition to the new_features_1_3 page. Plenty of

cleanup still to come..

  1. … 43 more files in changeset.
Update bind-8.1 docs in FAQ.

Update known_bugs with 1.2.1 relevance.

Remove some 192.168.x.x host references in known_bugs.

Add note about sunos 4.x and KeepAlive off.

  1. … 1 more file in changeset.
Removal of the Evil TAB Characters.

  1. … 12 more files in changeset.
Online docs appearance rework: pass 1, phase 2 - the

htdocs/manual/misc directory. Colour scheme set up and

page-top stuff centred.

  1. … 12 more files in changeset.
Add info on IRIX patches.

Big spelling and HTML cleanup of docs. Thanks go to weblint and ispell

and their authors.

  1. … 43 more files in changeset.
Update systems w/FIN_WAIT_2 timeout to reflect info I have received.

Adjusted some of the explanations of the FIN_WAIT_2 problems to

accurately reflect the current status, reasons why it occurs, and

what client authors should be doing. Also reformatted my mail

message appendix so that it is applicable to a non-Apache audience.

Modify the FIN_WAIT_2 docs page to change the info on Solaris (based on

information from Mukesh Kacker <>)

and add info on HP-UX (based on information from

Rick Jones <>).

Add more information on the FIN_WAIT_2 problem.

    • -0
    • +268
  1. … 1 more file in changeset.