SUMMARY: How to break CLOSE_WAIT
shah.bhavesh at gene.com
Tue Jan 31 12:25:52 EST 2006
Thanks to everyone for their detail explanation especially
CLOSE_WAIT means that the local end of the connection has received
a FIN from the other end, but the OS is waiting for the program at the
local end to actually close its connection.
The problem is your program running on the local machine is not closing
the socket. It is not a TCP tuning issue. A connection can (and quite
correctly) stay in CLOSE_WAIT forever while the program holds the
Once the local program closes the socket, the OS can send the FIN to
the remote end which transitions you to LAST_ACK while you wait for
the ACK of the FIN. Once that is received, the connection is finished
and drops from the connection table (if you're end is in CLOSE_WAIT
you do _not_ end up in the TIME_WAIT state).
Afaik, there is no ndd parameter which affects the tcp CLOSE_WAIT duration.
There was "tcp_close_wait_interval" but it has been obsoleted and renamed to
"tcp_time_wait_interval" because in reality it affects the TIME_WAIT timeout
and not the CLOSE_WAIT. So, you can try to change it but I doubt it'll have
any effect since they're different things...
Otoh, from what I know, it's the responsibility of an application (i.e. not
to the OS) to close its socket once the remote computer closes its side of
the TCP communication.
RF793 says CLOSE_WAIT is the TCP/IP stack waiting for the local application
to release the socket. So, it hangs because it has received the information
that the remote host has initiated a disconnection and is closing its
socket, upon what the local application did not close its own side.
So maybe the solution consists in finding a bug fix for your application...
Or more dangerously because they still have right to send remaining data in
queue, to kill processes in CLOSE_WAIT state...
CLOSE_WAIT connections indicate an error in the software.
It's a connection which has been torn down but your side of things
still has a filedescriptor open.
I believe CLOSE_WAIT on the server side of the connection means that the
server has received a FIN from the client, will have acknowledged this
back to the client and then informed the application that it can close
the connection. It is then up to the application to relinquish the
connection once it is satisfied that all the data has been read from the
connection. Once it relinquishes the connection the server will send a
final FIN back to the client and the connection will be fully closed.
If you are seeing a large number of connections persisting in
CLOSE_WAIT state it's probably a problem with the app itself, restarting
it will clear the connections temporarily but obviously further
investigation will be required to find the cause of the problem.
look at :
My original post was:
>When i perform netstat -a, i saw the hundreds of connections are in
>CLOSE_WAIT state. This causes my named-xfer using these connections to
>sleep, truss -p <process_pid>.
>Is there a timer to set, say after 120 seconds the CLOSE_WAIT
>connections will break so my program can reconnect again?? For example
>the "ndd" command??
>Any help is greatly appreciated.
>sunmanagers mailing list
>sunmanagers at sunmanagers.org
sunmanagers mailing list
sunmanagers at sunmanagers.org
More information about the summaries