Sockets stuck in FIN_WAIT_1

[Peter Jeremy]

On 2008-May-29 18:11:56 -0400, Robert Blayzor <rblayzor.bulk at inoc.net> wrote:
>working.  Only way to correct it seems to reboot the server...  even under 
>RELENG_7_0.... so the upgrade from 4_11 did not fix the problem.

Unfortunately, your issue is a bug in the client: The server is trying
to send data and the client is continuously reporting that it is still
around but can't accept the data right now.  The server is behaving
perfectly correctly.

As a work-around, you could write a cronjob that scans "netstat" and
temporarily creates an ipfw 'reset' rule that matches each FIN_WAIT_1
socket (possibly only if data is queued and/or matching packets that
advertise a 0 windowsize).  This rule would have to preceed any
check-state rule.  This is a hack but it will save you having to
reboot the server.  (Create them all with the same rule number and
delete that rule number as the first step in the cronjob would handle
rule cleanup).

A real solution would require more thought.  I suspect you need a
mechanism similar to the keepalive timer that starts when there is
data queued and is reset when (some) data is sent - this would catch
your situation but I'm not sure if it's a general solution.  I'm not
sure if one of the existing TCP timers could be (ab)used to achieve
this.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080530/e6a4baf9/attachment.pgp