Customer Service Center
Spirent KB Article
Doc ID: FAQ10386
Email Article Link
Ho do I free up hung sockets on an HP?
There was a situation where the ne_server sockets were hung up in PMI. I wan't to avoid having to reboot the
machine to free them up. I called HP and got these instructions which helped free up the sockets.
Wanted to pass it on in case you run into a similar issue. Remember to change the settings back to how
you found them.
Hidden for 11.0
Supported for 11i
If a connection is in the FIN_WAIT_2 state it has sent out it's FIN and
the other end has acknowledged it.
Unless we have done a half-close, we are waiting for the application on
the other send to recognize that it has received an end-of-file
notification and close its end of the connection, which sends us a FIN.
Only when the process at the other end does this close will our end move
from the FIN_WAIT_2 to the TIME_WAIT state.
This means our end of the connection can remain in this state forever.
The other end is still in CLOSE_WAIT state, and remains there forever,
until the application decides to issue the close.
In most cases this happens if the other ends application is no longer
running at all.
So there is nobody who will ever send us the FIN and we remain in the
With this timer it is possible to close the connection willingly from
our side to get rid of connections in the FIN_WAIT_2 state.
The problem lies normally on the other end of this connection, since we
only wait for something to happen.
So to solve this setting a timer is not really the solution, it would be
better to change the application which is not sending the FIN to us.
Unix version Minimum Maximum Default
11.0 0 undefined 0
11i 0 undefined 0
The value is given in milliseconds.
The minimum is 0 which means the timer is not active, we wait forever.
Even if there is no real minimum for this value, do not set it to
something below 10 minutes (600000). Otherwise you could violently close
connections which still are halfway active.
For 11.00 this option has no effect when socket caching is enabled
(tcp_conn_strategy is not null).
Why should this be changed?
Since a lot of application do not send the final FIN to end the
connection, it could happen that a huge amount of connection remains in
the FIN_WAIT_2 state.
To have a workaround until the real problem, the application on the
other end, is solved you could set this timer to something bigger than
Check the current value:
ndd -get \/dev/tcp tcp_fin_wait_2_timeout
Set the FIN_WAIT2 timeout to 11 minutes:
ndd -set /dev/tcp tcp_fin_wait_2_timeout 660000
nddconf entry example:
Product : UNIX,Perform