Received: (qmail 2205 invoked by uid 2012); 6 Oct 1998 22:48:24 -0000 Message-Id: <19981006224824.2204.qmail@hyperreal.org> Date: 6 Oct 1998 22:48:24 -0000 From: Werther Pirani Reply-To: werther@wservice.com To: apbugs@hyperreal.org Subject: netstat -a -f inet reports many connections in CLOSE_WAIT state X-Send-Pr-Version: 3.2 >Number: 3159 >Category: os-netbsd >Synopsis: netstat -a -f inet reports many connections in CLOSE_WAIT state >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: closed >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Tue Oct 6 15:50:00 PDT 1998 >Last-Modified: Thu Oct 8 04:40:00 PDT 1998 >Originator: werther@wservice.com >Organization: >Release: 1.3.1 >Environment: NetBSD home.wservice.com 1.3.2 NetBSD 1.3.2 (WSERVICE) #0: Wed Sep 30 10:07:29 EDT 1998 root@home.wservice.com:/usr/src/sys/arch/sparc/compile/WSERVICE sparc >Description: netstat -a -f inet reports many connections in CLOSE_WAIT state: tcp 0 0 home.www cotelli1.biodip..1141 CLOSING tcp 0 0 home.www ppp02-02.dial-ac.1932 CLOSING tcp 0 0 home.www ppp02-02.dial-ac.1923 CLOSING tcp 0 0 home.www net130-195.mclin.1133 CLOSING tcp 0 0 home.www net130-195.mclin.1120 CLOSING tcp 0 0 home.www 134.171.69.199.42423 CLOSING tcp 0 0 home.www pool001-max13.ds.1607 CLOSING tcp 0 0 home.www pool001-max13.ds.1601 CLOSING tcp 0 0 home.www a-mi26-41.tin.it.1351 CLOSING tcp 0 0 home.www w3inet-phx.sps.m.34379 CLOSING tcp 0 0 home.www dadovago1137.dad.1824 CLOSING tcp 0 0 home.www a-mi19-19.tin.it.1915 CLOSING tcp 0 0 home.www a-mi19-19.tin.it.1906 CLOSING tcp 0 0 home.www 205.163.88.73.1601 CLOSING tcp 0 0 home.www 205.163.88.73.1595 CLOSING tcp 0 0 home.www port50.ott.net.1658 CLOSING tcp 0 0 home.www isdn18.csi.unimi.1729 CLOSING tcp 0 0 home.www isdn11.csi.unimi.1334 CLOSING tcp 0 0 home.www 193.204.9.231.1261 CLOSING tcp 0 0 home.www 193.204.9.231.1256 CLOSING tcp 0 0 home.www 134.171.69.199.33304 CLOSING tcp 0 0 home.www isdn11.csi.unimi.1324 CLOSING tcp 0 0 home.www isdn11.csi.unimi.1321 CLOSING tcp 0 0 home.www isdn11.csi.unimi.1307 CLOSING tcp 0 0 home.www mac29ut.cuc.unip.1592 CLOSING tcp 0 0 home.www dialup-01-08-03..1837 CLOSING tcp 0 0 home.www dialup-01-08-03..1834 CLOSING tcp 0 0 home.www dialup-01-08-03..1818 CLOSING tcp 0 0 home.www 205.155.38.129.1448 CLOSING tcp 0 0 home.www a-mi37-46.tin.it.1469 CLOSING tcp 0 0 home.www a-mi37-46.tin.it.1466 CLOSING tcp 0 0 home.www a-mi37-46.tin.it.1458 CLOSING tcp 0 0 home.www a-mi37-46.tin.it.1445 CLOSING tcp 0 0 home.www a-mi65-24.tin.it.1711 CLOSING Most of the browsers are indentified as some version of Netscape for Macintosh PPC -- the odd Windows NT still pops up though. Server IS NOT stuck and continues servicig requests as usual. >How-To-Repeat: Connecting with Netscape PPC to the Apache server. >Fix: No, and looks like that using BrowserMatch to "downgrade" Macintosh as a whole doesn't help at all, e.g.: BrowserMatch "Macintosh" nokeepalive downgrade-1.0 force-response-1.0 Doesn't improve things. >Audit-Trail: State-Changed-From-To: open-closed State-Changed-By: marc State-Changed-When: Tue Oct 6 15:52:15 PDT 1998 State-Changed-Why: close_wait is a normal part of a connection. It is normal for such a state to stay around for several minutes after the connection is closed. The connection isn't actually open any more and very few resources are used to deal with it, but it is used to keep state to protect against old segments that may still be floating around the network. From: Marc Slemko To: werther@wservice.com Cc: apbugs@apache.org Subject: Re: os-netbsd/3159: netstat -a -f inet reports many connections in CLOSE_WAIT state Date: Tue, 6 Oct 1998 15:55:19 -0700 (PDT) On 6 Oct 1998 marc@apache.org wrote: > [In order for any reply to be added to the PR database, ] > [you need to include in the Cc line ] > [and leave the subject line UNCHANGED. This is not done] > [automatically because of the potential for mail loops. ] > [If you do not include this Cc, your reply may be ig- ] > [nored unless you are responding to an explicit request ] > [from a developer. ] > [Reply only with text; DO NOT SEND ATTACHMENTS! ] > > > Synopsis: netstat -a -f inet reports many connections in CLOSE_WAIT state > > State-Changed-From-To: open-closed > State-Changed-By: marc > State-Changed-When: Tue Oct 6 15:52:15 PDT 1998 > State-Changed-Why: > close_wait is a normal part of a connection. It is normal for ^^^^^^^^^^ Sorry, I read TIME_WAIT in your submission. TIME_WAIT is normal. > such a state to stay around for several minutes after the > connection is closed. The connection isn't actually open > any more and very few resources are used to deal with it, but > it is used to keep state to protect against old segments > that may still be floating around the network. > Hang on a sec. You said they were in CLOSE_WAIT, but you netstat shows them in CLOSING. Can you clarify exactly what you mean and why you think it is a problem? From: Werther Pirani To: marcs@znep.com Cc: apbugs@Apache.Org Subject: Re: os-netbsd/3159: netstat -a -f inet reports many connections in CLOSING state Date: Thu, 08 Oct 1998 13:38:39 +0200 > Hang on a sec. You said they were in CLOSE_WAIT, but you netstat > shows them in CLOSING. Can you clarify exactly what you mean > and why you think it is a problem? Sorry, my fault. I actually meant CLOSING. It's my understanding that a CLOSING state is entered as a result of a simultaneous close, which Steven describes as "rare but still possible". I think this is a problem because the connections stay in the CLOSING state and their sockets are never released. In addition, this happens only with different releases of Netscape for Macintosh PPC. Sincerely, Werther Pirani >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ]