From owner-freebsd-current  Mon May 19 06:22:52 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id GAA20707
          for current-outgoing; Mon, 19 May 1997 06:22:52 -0700 (PDT)
Received: from sierra.zyzzyva.com (ppp01-58.zyzzyva.com [208.214.58.10])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA20701
          for <freebsd-current@FreeBSD.ORG>; Mon, 19 May 1997 06:22:48 -0700 (PDT)
Received: from sierra (localhost [127.0.0.1]) by sierra.zyzzyva.com (8.8.5/8.8.2) with ESMTP id IAA09358; Mon, 19 May 1997 08:23:29 -0500 (CDT)
Message-Id: <199705191323.IAA09358@sierra.zyzzyva.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Developer <dev@flevel.co.uk>
cc: David Greenman <dg@root.com>, freebsd-current@FreeBSD.ORG
Subject: Re: FIN_WAIT_2 
In-reply-to: dev's message of Mon, 19 May 1997 13:04:17 +0100.
         <Pine.BSF.3.95q.970519130248.1321A-100000@fgate.flevel.co.uk> 
X-uri: http://www.zyzzyva.com/
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 19 May 1997 08:23:29 -0500
From: Randy Terbush <randy@zyzzyva.com>
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> 
> On Mon, 19 May 1997, David Greenman wrote:
> 
> > >Does anyone know if Freebsd times out FIN_WAIT_2's.. if so what is the
> > >timeout and what date was this put into the kernel?
> > 
> >    There have been a variety of timer changes over the past two years which
> > should catch cases >= CLOSING. Specifically, the persist timer is set on
> > connections >= CLOSING, so connections in FIN_WAIT_2 should be timed out by
> > that timer at the very least. My vague recollection is that a different timer
> > kills it before that, however.
> 
> Thanks for the information. It seems from testing on one of our machines
> that the timeout may be around 5 mins. It's unfortunate that apache seems
> to have no way to detect that the user has hit stop other than just
> leaving the conntion in FIN_WAIT_2 until the kernel times it out.
> 
> Regards,
> 
> Trefor S.
> 

The Apache Group has gone through considerable contortions on this 
issue. The FIN_WAIT_2 is not a result of a user pressing STOP, but 
rather the result of a half-close on the socket waiting for the 
client to either close or restart the connection. The are a number 
of reasons that this is needed. Visit the following URL for a more 
thorough explanation.


http://www.apache.org/docs/misc/fin_wait_2.html