CLOSE_WAIT

[Fabrizio Fiorito]

Hi all,
I need any infoo about this report by a
netstat -a command.
tcp 2003 0 farm_mar.5005 itmilas014.itmil.2452 CLOSE_WAIT

tcp 1679 0 farm_mar.5005 itmilas014.itmil.1998 CLOSE_WAIT

Well the scenario is :
HP-UX server with SAS
NT Web Server

On the server HP-UX is installed an application server SAS with a socket service defined on port 5005.
Sometimes the application server SAS refered to the port 5005 is locked and the strange thing is that sometimes, killing the proces, the port is locked yet.
For unlocking the port a reboot is needed !!
So, what does mean CLOSE_WAIT ?
How can I try to solve the problem ?
Thanks to all,
Fabrizio

[James R. Ferguson]

Hi:

The CLOSE_WAIT state is a normal transition state for a socket waiting to close. It is also known as FIN_WAIT_2. Handshaking occurs between server and client during the birth-to-death cycle of a socket connection.

If a client dies without engaging in a socket shutdown dialog then it is possible for a port to remain hung. A reboot is one (drastic) way to release the port.

On 11.x you can use 'ndd' to adjust various timers. See document #S3100001424A for some guidance with 'tcp_fin_wait_2_timeout'.

...JRF...

[Carsten Krege]

A CLOSE_WAIT is a normal state. You should check out a TCP state transition diagram that shows you how the various states are defined. E.g. try

http://www.nv.cc.va.us/home/kmorneau/tcp-ip/UDP-TCP/sld021.htm

Carsten

[rick jones]

CLOSE_WAIT and FIN_WAIT_2 are for lack of a better term symmetric states. If one side of a connection is in CLOSE_WAIT, the other side is in FIN_WAIT_2.

A connection enters CLOSE_WAIT when the remote sends a FIN, but the local side has not yet issued a close() or shutdown(). It is a state where TCP is waiting on the application to do something. If a connection appears to be "stuck" in CLOSE_WAIT it is an indication that either the communication is simplex (unidirectional) or (perhaps more likely) that the local application has not noticed (through coding bugs perhaps) that the remote has closed its end of the connection.

FIN_WAIT_2 is the state TCP enters when it has sent a FIN to the remote and has recieved an ACK of that FIN, and the remote (now in CLOSE_WAIT) has yet to send us a FIN. It is possible to get "stuck" in this state without there being a local bug if the remote does something stupid like use an abortive close (RST) of the connection. This is common in applications written for Windows. A RST segment is not retransmitted and so if it is lost, the local side can sit in FIN_WAIT_2 forever. This is what the tcp_keepalive_detached_interval settis is for. HP-UX 11 will automagically enable keepalives for "detached" (the app has called close()) connections and this will send a keepalive probe to the remote. Either the remote sends something (probably a RST) and we transition to CLOSED, or we timeout after the stack's normal retransmission heuristics.

If the process does indeed go away, any connection in CLOSE_WAIT will transition to CLOSED and all should be well. If that app has fork()ed and the remaining process(es) still have a file descriptor (socket) for that connection, it will remain in CLOSE_WAIT.

Server apps that are well-written will set SO_REUSEADDR before trying to bind() to their well-known port number. This will allow them to restart while old connections to the same well known port exist (in any state other than LISTEN). Server apps that are not well written (ie have bugs) will not set SO_REUSEADDR and should be shunned. (IMPO)

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