How to Remove a Close_Wait Socket Connection

How do I remove a CLOSE_WAIT socket connection

CLOSE_WAIT means your program is still running, and hasn't closed the socket (and the kernel is waiting for it to do so). Add -p to netstat to get the pid, and then kill it more forcefully (with SIGKILL if needed). That should get rid of your CLOSE_WAIT sockets. You can also use ps to find the pid.

SO_REUSEADDR is for servers and TIME_WAIT sockets, so doesn't apply here.

How can I get CLOSE_WAIT state of specification socket

#define SOCKET_ALIVE 10
#define SOCKET_DEAD 9

INT CheckSocketAlive(SOCKET socket2check)
{
    fd_set  fdR;
    struct  timeval timeout;
    timeout.tv_sec = 1;
    timeout.tv_usec = 0;
    FD_ZERO(&fdR);  
    FD_SET(socket2check, &fdR);
    switch (select(socket2check + 1, &fdR, NULL,NULL, &timeout))
    {  
    case SOCKET_ERROR:
        _tprintf(_T("\tError condition. Code : [%d]\n"), WSAGetLastError());
        return SOCKET_DEAD;
    case 0:
        return SOCKET_ALIVE;
    default:
        if ( FD_ISSET(socket2check, &fdR) )
        {
            _tprintf(_T("A read event has occurred on socket [socket2check].\n"));
            return SOCKET_DEAD;
        }
        break;
    }
}

You can get state of selected socket using this function.

But only SOCKET_ERROR or SOCKET_ALIVE.

You can change timeout.tv_sec (1sec) as you want.

Boost:ASIO acceptor stacks sockets in CLOSE_WAIT state after hours/days

I finally found a workaround fortuitously!

I've setup a task to check for CLOSE_WAIT sockets every hour and restart the ioservice if it found more than usual.

Surprisingly, the simple fact of running the ss command during the rise of CLOSE_WAIT states (and before reaching file descriptors limit) makes all the sockets in CLOSE_WAIT state switch to LAST_ACK and then release after few seconds...

Finally, the file descriptor limit is never reached and the ioservice has not to be restarted!!!

Exact command is (ran by the app process every hour) :
ss -n -p state close-wait | wc -l

Server graph with workaround :
https://ibb.co/qBTrykn

Troubleshooting connections stuck in CLOSE_WAIT status

The problem was a bug triggered by setting "Use JSSE SSL" to true in webLogic. Using WebLogic's own SSL implementation instead of JSSE is not a problem for our application, so I merely unchecked that setting and the problem disappeared.

TCP connections stuck with CLOSE_WAIT state

Finally I could'n find a way to solve problem to close connection within my code.

But I added a timer that close connection and it works just awesome!

private void ProcessClientRequests(object argument) 

 // ...  The same code of my quetion

 Timer timerCloseConn = new(new TimerCallback((e) =>
                            {

                                if (stream != null)
                                {
                                    stream.Close();
                                    stream.Dispose();
                                }
                                if (client != null)
                                {

                                    if (client.Client.Connected)
                                    {
                                        client.Client.Shutdown(SocketShutdown.Both);
                                    }

                                    client.Close();
                                    client.Dispose();
                                    client = null;
                                }

                                Logger.Info("The connection has been closed by 
 timer's rule!");
                            }), null, 60000, Timeout.Infinite);

  // ... The same code of my quetion
}

Golang http server app have many Socket (CLOSE_WAIT)

CLOSE-WAIT means that TCP is waiting for the local application to close the socket, having already received a close from the peer.

Maybe it is some kind of flooding(Example: Sync-flood)?

No. It is a bug in your code. You aren't closing a socket somewhere.

The problem seems to be not in the code.

The problem is in your code.

Code tested several times.

But not for this condition, or under the conditions that produce this problem.

But yesterday I did not have this problem.

So yesterday those condtiions did not occur.

(Code was not changed.)

So the bug has always been there.

---

Related Topics