Hi Maksim,

On Tue, May 21, 2019 at 01:47:30PM +0300, ?????? ????????? wrote:
> Hi!
> 
> I've run into some weird problem of many connections failed with SD status
> in log. And I have no idea how to discover the source of the problem.
> 
> >From the point of client it looks like this:
> * Client (located on the same machine as haproxy) successfully opens a
> connection to haproxy over loopback interfaces and sends http/1.1
> get-request.
> * haproxy accepts request (ack was send)
> * after some time passed (usually 1ms longer then "timeout connect" set)
> haproxy just sends tcp-FIN with no user data in the packet.
> 
> >From the point of haproxy I see this:
> 2019-05-21T13:30:02+03:00 haproxy[608365] local2.info 127.0.0.1:54064
> [21/May/2019:13:30:01.289] some-host some-host/backend:80 0/1000/0/-1/1001
> -1 0 - - SD-- 164/19/18/0/+1 0/0 "GET /some-request HTTP/1.1"
> 
> And it doesn't matter how many retries I set for this backend section in
> config.
> Can you give me a hint, how to discover a real reason  of this errors?

It looks like a bug. You should have a 502 error sent to the client,
not just a silent close (unless you're purposely sending an empty 502
error file of course). Well in fact if haproxy really blocked on data
but received correct headers, it's normal not to forge a 502 response,
but there should be the server's headers at least.

Now what I'm seeing at this point from the log is that haproxy successfully
connected to the server but didn't receive valid headers in response. The
"SD" status is thus not correct. You should have "SH" there in this case.
You can try to issue "show errors" on the CLI to see if something invalid
was detected in the response. If you don't have anything, then you'll have
to start tcpdump between haproxy and the server. Given that the termination
state doesn't match the timers, there is a bug somewhere, so everything
is imaginable from this point. I'm interested in knowing what case triggers
this, of course.

Regards,
Willy

Reply via email to