[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state
From: |
Christian Grothoff |
Subject: |
Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state |
Date: |
Sat, 5 Jan 2019 08:06:25 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 |
Ah, sorry, I confused CLOSE_WAIT with TIME_WAIT. Hmm. You wrote that you
set the timeout to 0, which means "disable". Maybe that is the issue?
On 1/5/19 5:34 AM, Santos Das wrote:
> Hi Christian,
>
> We see that it never times out, i.e remain in CLOSE_WAIT state forever.
>
> Also, it is seen irrespective of whether we use loop back ip or a
> regular eth0 IP.
>
> From my reading, I understand the following and we don't see that FIN is
> received from Client but , we don't send FIN.
> 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.
>
>
>
> On Sat, Jan 5, 2019 at 4:36 AM Christian Grothoff <address@hidden
> <mailto:address@hidden>> wrote:
>
> Hi Santos,
>
> CLOSE_WAIT is a TCP state in the kernel after a TCP connection is
> finished. It typically lasts like 60--300s, depending on your kernel
> configuration (you may want to read up on the TCP state machine).
> You can change the time by changing
> /proc/sys/net/ipv4/tcp_fin_timeout, but usually this is not an issue
> (unless you have _way_ too many TCP connections from the same host, I've
> only seen this matter on loopback, in which case usually enabling
> keep-alive on the client-side helps).
>
> Summary: this is not an issue in MHD, likely not one for anyone, just a
> TCP artifact.
>
> Happy hacking!
>
> -Christian
>
> On 1/4/19 6:29 PM, Santos Das wrote:
> > Hi Christian,
> >
> > Please note I am using suspend-resume and not
> > implementing MHD_OPTION_NOTIFY_CONNECTION to close . Not sure when the
> > library closes the connection after it receives FIN and move to
> CLOSE_WAIT.
> >
> > Any pointers?
> >
> > thanks, santos
> >
> > On Fri, Jan 4, 2019 at 10:27 PM Santos Das <address@hidden
> <mailto:address@hidden>
> > <mailto:address@hidden <mailto:address@hidden>>> wrote:
> >
> > Hi Christian,
> >
> > Wishing you a happy new year!
> >
> > We have set the MHD_OPTION_CONNECTION_TIMEOUT to 0 and we see that
> > all the connections remain in CLOSE_WAIT state.
> >
> > We also have set the MHD_OPTION_CONNECTION_LIMIT to 1000 .
> >
> > Any idea what could be wrong ?
> >
> > Thanks, Santos
> >
>
signature.asc
Description: OpenPGP digital signature
- [libmicrohttpd] Sockets remain in CLOSE_WAIT state, Santos Das, 2019/01/04
- Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state, Santos Das, 2019/01/04
- Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state, Christian Grothoff, 2019/01/04
- Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state, Santos Das, 2019/01/04
- Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state, Santos Das, 2019/01/04
- Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state, Christian Grothoff, 2019/01/05
- Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state, Santos Das, 2019/01/05
- Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state, Christian Grothoff, 2019/01/07
- Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state,
Christian Grothoff <=