FIN_WAIT2
Tony
tcp 0 0 x.x.x.x:80 129.59.151.138:3100 FIN_WAIT2
tcp 0 0 x.x.x.x:80 66.134.47.229:49340 FIN_WAIT2
tcp 0 0 x.x.x.x:80 66.134.47.229:49341 FIN_WAIT2
tcp 0 0 x.x.x.x:80 66.134.47.229:49342 FIN_WAIT2
Barry Margolin
It means that you've closed the connection, but the remote process (the
browser, in this case) hasn't. If the browser uses persistent connections,
your server may have timed out waiting for it to issue a new command, so it
closed the connection, but the browser hasn't noticed that the connection
closed.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
James Carlson
> What are FIN_WAIT2 connections? I see them on my web server port 80.
They mean that the web server closed the connection first, received an
ACK from the peer that covers the sequence number for the FIN it sent,
and it's now waiting for a FIN from the peer. It's one of the two
possible half-open connection states. The other side should be in the
opposing state -- it should be stuck in CLOSE_WAIT.
Generally, this means that the peer application has a bug. It's
either failing to detect the socket closure (note that the ACK comes
from the kernel, not the application), call close() when it should, or
it did fork() and accidentally leaked a descriptor. (That's all
assuming some flavor of Unix. If the peer isn't Unix, I'm sure
there's some analog of all of this ...)
--
James Carlson, Solaris Networking <james.d...@east.sun.com>
SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
Rick Jones
It means that the application on your side has called close() or
shutdown() and your local TCP stack has sent a FINished segment to the
remote TCP and has received an ACKnowledgement segment from same.
As for what has happened on the remote:
1) The remote application has called close() or shutdown() but has
previously tweaked the socket with setsockopt(SO_LINGER) to use an
"abortive" close (or has not untweaked the client stack's bogus
default behaviour if the stack defaults to it). An abortive close
sends a RST (reset) segment, and while FIN segments are
retransmitted until an ACK arrives, RST segments are not. So, if
the RST segment is lost...
2) The remote application has not called close() or shutdown() it its
end. In general this would be a bug _unless_ the application was
written to use the TCP connection in a simplex (unidirectional)
manner - HTTP is not such a thing.
There are some other possiblities, but those are the most likely - I
would guess that 1 is much more likely than two.
In and of itself that isn't sooo bad, except that the FIN_WAIT_2 state
is a "passive" state - the TCP connection will simply sit there until
it hears something from the remote.
If your local application has called setsockopt(SO_KEEPALIVE) on the
sockets, the "normal" TCP Keepalive mechanisms should cull those
connections after some time - perhaps two hours. On other stacks
(HP-UX 11 is one with which I am familiar, others may do it too) when
the application calls close(), it will automagically enable the
keepalives even if the application had not previously called
setsockopt. In this case the keepalives will start much sooner
(tcp_keepalive_detached_interval versus tcp_keepalive_interval in the
case of HP-UX 11). Some stacks may have an "arbitrary" FIN_WAIT_2
timer that is started when the connection goes into FIN_WAIT_2 - this
is an implementation detail, and not part of the de jure TCP
specification (IIRC).
rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...
Kurtis D. Rader
> Generally, this means that the peer application has a bug. It's either
> failing to detect the socket closure (note that the ACK comes from the
> kernel, not the application), call close() when it should, or it did fork()
> and accidentally leaked a descriptor.
The latter is surprisingly common. As a senior software support engineer for
IBM I am regularly tasked by our customers to prove our kernel is doing the
right thing. Just a couple of weeks ago a major telecom firm in North America
complained that our TCP stack was broken. They swore up and down their process
was closing the socket but no FIN was being sent. The FIN would eventually be
sent anywhere from a few minutes to eighteen minutes after the process closed
the socket.
Making diagnosis difficult was that this happened infrequently. We used
tcpdump, etc. and could find nothing amiss. Eventually we got a copy of
lsof(1) on their system and found another process had the socket open! Sure
enough, the customer admitted that a small percentage of the connections to
their application resulted in another process being spawned to handle
housekeeping chores. Bingo! They weren't setting the FD_CLOEXEC flag on the
socket file descriptor nor were they explicitely closing it before spawning
the other process. The housekeeping process would eventually finish and upon
exiting cause the kernel to reduce the reference count on the inherited file
descriptor to zero thus allowing the socket to really be closed :-)