The ndd parameter
tcp_fin_wait_2_timeout can be tuned to adjust how long the side in FIN_WAIT_2
remains in that status, the default being forever and set by value ‘0’ (zero).
On the two systems, ‘system1’ and ‘system2’ , ‘tcp_fin_wait_2_timeout’ has a
value set to ‘0’. Hence the connection will never time out and will stay open
until either the fin is received or the system is rebooted. Setting the value
to some non-zero value will make the connection be reset when the time value
that we set (in milliseconds) has been reached.
CLOSE_WAIT is also one of the
states of a TCP socket during the life of the connection and do not generally
indicate any issue.
The CLOSE_WAIT state indicates
that the remote end of the connection has finished transmitting data and that
the remote applications has issued a close or shutdown call. The local
TCP stack is now asking for the local application that owns the socket to close
the local socket as well. When a socket remains in the CLOSE_WAIT state for a
long period it typically indicates some issue with the local application that
prevents it from closing the local socket. The application may have coding
issues or hung or may just be busy doing other work at the moment. There is no
way, from the TCP side, to tell why the socket has not been closed and will
require examining the application(s) that still have not closed the socket.
To determine which process or
processes still have the socket open locally, public domain tool ‘lsof’ could
be used. From its output, look for the specific socket with a run string
such as:
# lsof -i tcp:<port> --
This will show the process(es) that have socket tied to the local port number
specified open at the moment
Action plan to rectify issues
with FIN_WAIT_2:
·
# ndd –set /dev/tcp
tcp_fin_wait_2_timeout 600000 – setting tcp_fin_wait_2_timeout
for 10 mins
·
/etc/rc.config.d/nddconf
– edit this file add entries of tcp_fin_wait_2_timeout
in to this file to restrain the values across reboots
No comments:
Post a Comment