Bug 14026

Summary:	Many network connections get left in the 'CLOSING' state
Product:	Base System	Reporter:	rob <rob>
Component:	kern	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	3.2-STABLE
Hardware:	Any
OS:	Any

Description rob 1999-09-29 00:20:01 UTC

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.

Fix: 

Unknown.
How-To-Repeat: The stuck connections gradually start appearing during normal usage on the machine.

Comment 1 Garrett A. Wollman 1999-09-29 02:01:45 UTC

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

Comment 2 rob 1999-09-29 02:26:34 UTC

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

Comment 3 Mike Barcroft freebsd_committer

2001-07-21 02:54:57 UTC

State Changed
From-To: open->closed


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