topic Re: netstat CLOSE_WAIT connection in Operating System - HP-UX

netstat CLOSE_WAIT connection

Shivkumar — Thu, 30 Jun 2005 08:31:26 GMT

Hi,

I see some CLOSE_WAIT connections for HP Apache on hpux 11.

There are some 7-8 CLOSE_WAIT connection when i issued "netstat -an" command. Are these connections undesirable ?

If yes, how should we close these connections ?

Thanks,
Shiv

Re: netstat CLOSE_WAIT connection

KVK — Thu, 30 Jun 2005 08:38:57 GMT

If you restart the APACHE & HP TOMCAT applications do you still see the same error ?

Can you check it out ?

Re: netstat CLOSE_WAIT connection

David Child_1 — Thu, 30 Jun 2005 08:44:50 GMT

This is caused by the client not sending a TCP FIN which leaves the socket in CLOSE_WAIT. There are ways to clean these up using 'ndd', but I don't think 7 to 8 of these is any big problem. Someone else may have a different point of view on that.

David

Re: netstat CLOSE_WAIT connection

RAC_1 — Thu, 30 Jun 2005 08:57:40 GMT

The number is not very big. This really shold be taken care of by client. Looks like client is not sending close to the server.

The ndd parameter, tcp_time_wait_interval decides how long it will wait in TIME_WAIT.
The default is 60 seconds and looks fine.

Anil

Re: netstat CLOSE_WAIT connection

rick jones — Fri, 01 Jul 2005 12:02:15 GMT

David - CLOSE_WAIT is when the local TCP _has_ received a FIN, and is waiting for the local application to call close() or shutdown().

CLOSE_WAIT can be a valid "send only" state, perhaps the client closed-out an http keepalive connection before the server finished sending all the data and then bothered to check for the read return of zero on the socket.

(FWIW, the remote TCP will be in FIN_WAIT_2 - most likely at least. It could I suppose be in FIN_WAIT_1, and depending on how it was written, it could even be completely gone, though that is unlikely, and since there is still a controlling socket on this end, does not represent the same issues as FIN_WAIT_2's have historically)

A handful of these are not likely to be a problem. The way to close them should it become required, would be to terminate the owning process(es).

As possibly already mentioned, CLOSE_WAIT is distinct from TIME_WAIT and tcp_time_wait_interval has no bearing on a connection in CLOSE_WAIT

Re: netstat CLOSE_WAIT connection

Sandman! — Fri, 01 Jul 2005 12:30:47 GMT

CLOSE_WAIT connection means that the remote host has sent a FIN (closed the connection) but the process on the local host hasn't.

Attached is a perl script that you can use to close all the connections that are in CLOSE_WAIT state.

This script uses ndd 'tcp_discon_by_addr' to remove a socket using the ip address represented by a hexadecimal number. It creates a 24 byte string that contains the hex representation of the 'quadruple' IP address Local 'IP+Local Port+Remote IP+Remote Port'.

best of luck!

Re: netstat CLOSE_WAIT connection

Sandman! — Fri, 01 Jul 2005 12:34:12 GMT

Sorry I attached the wrong script. Here's what you need.

regards!

Re: netstat CLOSE_WAIT connection

rick jones — Fri, 01 Jul 2005 12:35:50 GMT

man I wish we'd never shipped that ndd disconnect stuff. since there is still a socket associated with a CLOSE_WAIT connection, there should never be a need to use the fision-byproduct producing ndd tcp_disconn* stuff - simply terminating the owning process should suffice. Then get the developers of the owning process application code to fix it so it does not leave connections in CLOSE_WAIT in the first place - except when it is supposed to.

So, before worrying about a CLOSE_WAIT connection, make sure it has been there for a _very_ long time, and even then it may not be a real problem.