From owner-freebsd-stable@FreeBSD.ORG  Fri May 30 00:55:48 2008
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Delivered-To: freebsd-stable@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 50B771065672
	for <freebsd-stable@freebsd.org>; Fri, 30 May 2008 00:55:48 +0000 (UTC)
	(envelope-from dillon@apollo.backplane.com)
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by mx1.freebsd.org (Postfix) with ESMTP id 9D9278FC0A
	for <freebsd-stable@freebsd.org>; Fri, 30 May 2008 00:55:47 +0000 (UTC)
	(envelope-from dillon@apollo.backplane.com)
Received: from apollo.backplane.com (localhost [127.0.0.1])
	by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m4U0tkm4027966;
	Thu, 29 May 2008 17:55:46 -0700 (PDT)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.14.1/8.13.4/Submit) id m4U0tkqx027965;
	Thu, 29 May 2008 17:55:46 -0700 (PDT)
Date: Thu, 29 May 2008 17:55:46 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200805300055.m4U0tkqx027965@apollo.backplane.com>
To: Robert Blayzor <rblayzor.bulk@inoc.net>
References: <B42F9BDF-1E00-45FF-BD88-5A07B5B553DC@inoc.net>	<1A19ABA2-61CD-4D92-A08D-5D9650D69768@mac.com>	<23C02C8B-281A-4ABD-8144-3E25E36EDAB4@inoc.net>	<483DE2E0.90003@FreeBSD.org>	<B775700E-7494-42C1-A9B2-A600CE176ACB@inoc.net>	<483E36CE.3060400@FreeBSD.org>	<483E3C26.3060103@paradise.net.nz>	<483E4657.9060906@FreeBSD.org>
	<483EA513.4070409@earthlink.net>
	<96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net>
	<483EAED1.2050404@FreeBSD.org>
	<200805291912.m4TJCG56025525@apollo.backplane.com>
	<14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net>
	<200805291930.m4TJUeGX025815@apollo.backplane.com>
	<0C827F66-09CE-476D-86E9-146AB255926B@inoc.net>
	<200805292132.m4TLWhCv026720@apollo.backplane.com>
	<CCBAEE3E-35A5-4BF8-A0B7-321272533B62@inoc.net>
Cc: freebsd-stable@freebsd.org
Subject: Re: Sockets stuck in FIN_WAIT_1
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>, 
	<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 30 May 2008 00:55:48 -0000


:This is exactly what we're seeing, it's VERY strange.  I did kill off  
:Apache, and all the FIN_WAIT_1's stuck around, so the kernel is in  
:fact sending these probe packets, every 60 seconds, which the client  
:responds to... (most of the time).

    Ach.  Now that I think about it, it is still possible for it to
    happen that way.  Apache closed the connection while there was
    still data in the scoket buffer to the client.  The client then
    refused to read it, but otherwise left the connection alive.

    It's got to a be a bug on the client(s) in question.  I can't think
    of anything else.   You may have to resort to injecting a TCP RST
    packet (e.g. via a TUN device) to clear the connections.

						-Matt