From nobody@FreeBSD.ORG Tue Sep 28 16:16:06 1999
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id BEF2114FA5; Tue, 28 Sep 1999 16:16:06 -0700 (PDT)
Message-Id: <19990928231606.BEF2114FA5@hub.freebsd.org>
Date: Tue, 28 Sep 1999 16:16:06 -0700 (PDT)
From: rob@ideal.net.au
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: Many network connections get left in the 'CLOSING' state
X-Send-Pr-Version: www-1.0

>Number:         14026
>Category:       kern
>Synopsis:       Many network connections get left in the 'CLOSING' state
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Sep 28 16:20:01 PDT 1999
>Closed-Date:    Fri Jul 20 18:54:57 PDT 2001
>Last-Modified:  Fri Jul 20 18:55:41 PDT 2001
>Originator:     Rob Wise
>Release:        FreeBSD 3.2-STABLE from July 1999
>Organization:
>Environment:
FreeBSD proton.ideal.net.au 3.2-STABLE FreeBSD 3.2-STABLE #2: Thu Jul 15 11:04:40 EST 1999     rob@proton.ideal.net.au:/usr/src/sys/compile/PROTON  i386

>Description:
The machine displaying this problem is running squid and 2 fairly busy websites which have large files on them.  I'm not sure if file size is related.

After the machine has been up and running for a while many connections are visible in netstat which are stuck in the 'CLOSING' state.  For example:
tcp        0      0  proxy1.syd.8080        port19.syd.2197        CLOSING
tcp        0      0  proxy1.syd.8080        port56.cam.1779        CLOSING

These connections can't be cleared by shutting down either the squid or apache daemons.  The machine must be restarted to clear them.

The machine has 512MB of ram, a PII350 processor, Adaptec 2940UW scsi controller, and a Netgear 10/100 nic using the de0 driver.  Tcp extensions are turned off too.
>How-To-Repeat:
The stuck connections gradually start appearing during normal usage on the machine.
>Fix:
Unknown.

>Release-Note:
>Audit-Trail:

From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To: rob@ideal.net.au
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: kern/14026: Many network connections get left in the 'CLOSING' state
Date: Tue, 28 Sep 1999 21:01:45 -0400 (EDT)

 <<On Tue, 28 Sep 1999 16:16:06 -0700 (PDT), rob@ideal.net.au said:
 
 > tcp        0      0  proxy1.syd.8080        port19.syd.2197        CLOSING
 > tcp        0      0  proxy1.syd.8080        port56.cam.1779        CLOSING
 
 Sorry, that's Just The Way TCP Works.  In particular, this can happen
 if the client completely disconnects from the network at an
 inopportune moment.(*)  Eventually TCP will send a probe to that address
 while some other user is connected; when this happens, the other end
 will reply with a reset and the state for this connection will be
 zapped.
 
 -GAWollman
 
 (*)Specifically, CLOSING state is normally entered when:
 	a) the other end requested close before we are ready
 	b) we eventually agree to close
 	c) by which time the other end has gone away
 
 It is possible, but unlikely, for CLOSING state to be entered by other
 means as well.
 
 --
 Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
 wollman@lcs.mit.edu  | O Siem / The fires of freedom 
 Opinions not those of| Dance in the burning flame
 MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad Irschick
 

From: "Rob Wise" <rob@ideal.net.au>
To: "Garrett Wollman" <wollman@khavrinen.lcs.mit.edu>
Cc: <freebsd-gnats-submit@FreeBSD.ORG>
Subject: Re: kern/14026: Many network connections get left in the 'CLOSING' state
Date: Wed, 29 Sep 1999 11:26:34 +1000

 ----- Original Message -----
 From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
 To: <rob@ideal.net.au>
 Cc: <freebsd-gnats-submit@FreeBSD.ORG>
 Sent: Wednesday, September 29, 1999 11:01 AM
 Subject: kern/14026: Many network connections get left in the 'CLOSING'
 state
 
 
 > <<On Tue, 28 Sep 1999 16:16:06 -0700 (PDT), rob@ideal.net.au said:
 >
 > > tcp        0      0  proxy1.syd.8080        port19.syd.2197
 CLOSING
 > > tcp        0      0  proxy1.syd.8080        port56.cam.1779
 CLOSING
 >
 > Sorry, that's Just The Way TCP Works.  In particular, this can happen
 > if the client completely disconnects from the network at an
 > inopportune moment.(*)  Eventually TCP will send a probe to that address
 > while some other user is connected; when this happens, the other end
 > will reply with a reset and the state for this connection will be
 > zapped.
 
 How often are these probes supposed to be sent?  Some of these connections
 have been around for well over a month.  I've started a tcpdump on one of
 the hosts with a 'CLOSING' connection open and I'll see what happens.
 
 Rob
 
From: Rob Wise <rob@ideal.net.au>
To: Gene & <stark@cs.sunysb.edu>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: TCP connections in CLOSING state (kern/14026)

 On Tue, 14 Dec 1999, Gene & wrote:
 
 > I was just reading your bug report (kern/14026) in the GNATS database,
 > and Garrett Wollman's response.
 > 
 > A few hours ago, I updated a busy web server from FreeBSD 2.2.5 to
 > FreeBSD 3.2.  I have more or less immediately noticed the accumulation
 > of TCP connections in the CLOSING state.  This causes me difficulty
 > with respect to stopping and starting the custom web server I am
 > running on this host.
 > 
 > FreeBSD 2.2.5 did not suffer from this problem, so either I have to
 > disagree with Garrett in his assessment that "this is how TCP works",
 > or there have been some other TCP parameters that have been introduced
 > with new or different values between 2.2.5 and 3.2.
 > 
 > Did you figure out any solution to your problem?  I'd be interested
 > to hear if you did.  Thanks.
 
 Hi Gene,
 
 I have recieved no further contact from the FreeBSD team about the
 problem, but I believe someone may have fixed it shortly after I submitted
 this PR.  I have a machine running a later 3.3-STABLE, and one with 3.4-RC
 and neither show this problem any more.
 
 I think 3.4 will be out some time in the next month, and shouldn't have
 this problem any more.
 
 The machine I have that doesn't show this problem is running a kernel:
 
 FreeBSD no2.ideal.net.au 3.3-STABLE FreeBSD 3.3-STABLE #2: Tue Nov 30
 11:18:15 EST 1999
 
 Cheers,
 
 Rob

State-Changed-From-To: open->closed 
State-Changed-By: mike 
State-Changed-When: Fri Jul 20 18:54:57 PDT 2001 
State-Changed-Why:  

As per the Audit-Trail, the originator believes the problem has 
been solved. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=14026 
>Unformatted:
