Sockets in CLOSE_WAIT state
diego at woitasen.com.ar
Wed Apr 24 16:41:46 PDT 2013
On Wed, Jan 2, 2013 at 11:24 PM, Juli Mallett <juli at clockworksquid.com> wrote:
> If you can reproduce it with a single connection, it should be very
> easy to track down with logging statements. I would guess that it's
> one of two things:
> (1) the polling mechanism isn't telling the upper layers when the
> remote side has closed the connection, and so the upper layers don't
> realize they need to close the connection
> (2) could be a bug in the zlib or xcodec pipes causing them to not
> generate EOS and make the proxy close the connection.
> There's other possibilities, but I'd start by instrumenting as much as
> possible to figure out if anything is reacting to the FIN, and whether
> anything should be reacting to the FIN.
> On Wed, Jan 2, 2013 at 5:04 PM, Diego Woitasen <diego at woitasen.com.ar> wrote:
>> I was testing Wanproxy for HTTP (with Squid behing the Wanproxy
>> Server) and I'm running out of file descriptors frequently. In the
>> server side, netstat shows a lot of CLOSE_WAIT sockets. This looks
>> like a bug in the code, which is not closing all the sockets properly.
>> Any hint to find where the bug is?
>> Diego Woitasen
>> wanproxy mailing list
>> wanproxy at lists.wanproxy.org
It's been a long time. After few months I started again to debug
this bug trying to fix it. I was able to reproduce it with release
0.8.0 and the latest trunk (today checkout).
The only way that I found to reproduce the issue easily is under
wget -> wp client -> wp-server -> squid
and then executing:
wget --max-redirect=0 www.clarin.com.ar
Using wp client as proxy. It fails 99% of the times.
I couldn't reproduce it using netcat and haven't had time to write a
test case, but with Squid using default config and wget it's very easy
to reproduce. The problem appears when Squid and Wget tear down the
connection at almost the same time. If you try it with other pages
sometimes fails, sometimes not.
I went deep in to the code and I think that I found two bugs related
with this problem:
1- WP signalling isn't working properly. When the socket appears in
the CLOSE_WAIT state I see the EOS msg from the server to the client
and the EOS_ACK from the client to the server. When the socket is
closed properly, I see the EOS and the EOS_ACK in both ways. (what's
the right behavior? I think the latest one).
2- When the problem appears, the client closes the socket, it sends
the FIN,ACK and ACK just after the EOS/EOS_ACK exchange. The server
isn't detecting that the socket was closed because a read is never
scheduled again from the socket. I undertand that signalling is not
working fine, but WP should handle this case.
I'll continue to debug and to try to fix this issue in the next days.
Hints are welcome.
More information about the wanproxy