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
