Hi Willy, 2015-09-29 18:27 GMT+02:00 Willy Tarreau <[email protected]>: > On Tue, Sep 29, 2015 at 02:58:04PM +0200, joris dedieu wrote: >> kevent(3,0x0,0,{},5,{1.000000000 }) = 0 (0x0) >> kevent(3,0x0,0,{0x4,EVFILT_READ,0x0,0,0x1,0x0},5,{1.000000000 }) = 1 (0x1) >> accept(4,{ AF_INET 80.247.233.242:48068 },0x7fffffffe804) = 5 (0x5) >> fcntl(5,F_SETFL,O_NONBLOCK) = 0 (0x0) >> recvfrom(5,0x801407000,16384,0x20080,0x0,0x0) ERR#35 'Resource >> temporarily unavailable' >> setsockopt(0x5,0x0,0x4,0x48668c,0x4,0x0) = 0 (0x0) >> setsockopt(0x5,0x6,0x1,0x48668c,0x4,0x0) = 0 (0x0) >> accept(4,0x7fffffffe808,0x7fffffffe804) ERR#35 'Resource >> temporarily unavailable' >> shutdown(5,SHUT_WR) = 0 (0x0) >> close(5) = 0 (0x0) >> >> Has you can see it doesn't looks great. > > OK I found the reason, in my case the RST I was seeing was caused by pending > data otherwise haproxy didn't send it by itself since we're facing the client. > I've fixed it so that lingering is *really* disabled this time. You can retry
Ok that fix the issue. I get the same tcp sequence on both Linux and FreeBSD. 08:15:25.552414 IP jau31-2-82-236-20-129.fbx.proxad.net.33355 > ladybug2.rmdir.fr.22222: Flags [S], seq 1066137200, win 29200, options [mss 1460,sackOK,TS val 15996126 ecr 0,nop,wscale 7], length 0 08:15:25.552427 IP ladybug2.rmdir.fr.22222 > jau31-2-82-236-20-129.fbx.proxad.net.33355: Flags [S.], seq 1788015248, ack 1066137201, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 524803316 ecr 15996126], length 0 08:15:25.589643 IP jau31-2-82-236-20-129.fbx.proxad.net.33355 > ladybug2.rmdir.fr.22222: Flags [.], ack 1, win 229, options [nop,nop,TS val 15996135 ecr 524803316], length 0 08:15:25.590207 IP ladybug2.rmdir.fr.22222 > jau31-2-82-236-20-129.fbx.proxad.net.33355: Flags [F.], seq 1, ack 1, win 1040, options [nop,nop,TS val 524803354 ecr 15996135], length 0 08:15:25.590340 IP ladybug2.rmdir.fr.22222 > jau31-2-82-236-20-129.fbx.proxad.net.33355: Flags [R.], seq 2, ack 1, win 1040, options [nop,nop,TS val 524803354 ecr 15996135], length 0 > with the attached patch if you want. The second one will get rid of the > useless recvfrom() call if your system doesn't have TCP_QUICKACK. The third Yes as far as I know there is no per socket option for this on FreeBSD (only the system wild net.inet.tcp.delayed_ack variable). The recvfrom disappears as expected. Many thanks Joris > patch addresses a build issue reported off-list on another FreeBSD machine > (SOL_IP not defined). > > Thanks, > Willy >
