FIN_WAIT_2 problems

[Barbara Flynn_1]

Hi

I have several FIN_WAIT_2s in a netstat between a couple of my servers. I would have expected netstat to return ESTABLISHED but something has gone wrong somewhere!!! I need to find the processes that own the FIN_WAITs but lsof returns nothing for me.

Anyone any idea of any other way of tracing these FIN_WAITs back??

[Fabio Ettore]

Hi Barbara,

just see the following link; Bill Hassell explains very well FIN_WAIT_2:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=31974

I hope this helps you.

Best regards,
Ettore

[rick jones]

I would be _very_ cautious using the tcp_fin_wait2_timeout setting. FIN_WAIT_2 is indeed a perfectly valid recieve-only state for a TCP connection.

If the TCP connection is detatched (the application has called close()) then after tcp_keepalive_detatched_interval, the local TCP will start sending keepalive probes. If no reply to those probes is received within tcp_ip_abort_interval, the connection in FIN_WAIT_2 will be terminated.

If the TCP connection is _not_ detatched (that is the application has called shutdown(), but not close(), then I believe the tcp_keepalive_detatched_interval timer does not come into play. However, if the application has set SO_KEEPALIVE, after tcp_keepalive_interval of idleness, keepalive probes will be sent. Again, if no response is forthcoming from the remote within tcp_ip_abort_interval, the connection will be terminated.

If a response to the keepalive probes is received (and is not a RST segment :) then the connection will remain alive, as this implies that the connection is still "valid."

Lsof can be used to try to associate connections with processes. If lsof does not show a process for the connection, that suggests the application has indeed called close().

A well-written application will either have application-level keepalives or timeouts, or will enable SO_KEEPALIVE.

ftp://ftp.cup.hp.com/dist/networking/briefs/annotated_ndd.txt

[Doug Burton]

The above way to do things certainly seems the best way to go. However, if you absolutely need to blow the "FIN_WAIT_2"s away without a reboot you can run the attached. It cooks them all which may not be the best thing to do.