[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state

From: Santos Das
Subject: Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state
Date: Sat, 5 Jan 2019 19:45:16 +0530

Hi Christian,

Thanks for the quick response and I must thank you for all the support.

Since socket close is called by MHD, could you please let me know in which conditions MHD will not close the socket after receiving the FIN from the client side? Also, please note I am seeing this problem in the traffic testing only and at the end of testing , I see the connections remain in CLOSE_WAIT state forever.

Indicates that the server has received the first FIN signal from the client and the connection is in the process of being closed

So this essentially means that his is a state where socket is waiting for the application to execute close()

A socket can be in CLOSE_WAIT state indefinitely until the application closes it. 
Faulty scenarios would be like filedescriptor leak, server not being execute close() on socket leading to pile up of close_wait sockets

On Sat, Jan 5, 2019 at 12:41 PM Christian Grothoff <address@hidden> wrote:
On 1/5/19 5:51 AM, Santos Das wrote:
> Hi Christian,
> We see that at the end of the load run, the connections at the TCP
> server remain in CLOSE_WAIT state. We didn’t see this for single call.
> Also, I wanted to tell you that all our connection are initiated from a
> single IP as that is the load balancer IP and we are behind that.

The single IP should hardly matter.

> We also observed that it  gets stuck in the CLOSE_WAIT state and remains
> there forever , i.e Sockets are seen in this state even after the
> default of TCP connection timeout.

What kind of method do you use to generate the response?

> From all my study, it points out the TCP stack  will keep the connection
> in CLOSE_WAIT state till the application call close on the socket.  

Right, so the question now is why the socket is not closed. Two
reasons are clearly coming together: (1) you disabled the timeout,
(2) for some reason MHD believes the response is not done. So we
should also figure out why your response is not considered "finished" by

> Do we know when MHD call close normally ? Is there any instrumentation
> that could tell us why /whether FIN is sent from the Server or NOT ? 

You could just 'strace' and look for the close() call, but that won't
tell you where exactly the issue is.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]