On Thu, Mar 22, 2012 at 01:01:50AM +0100, Mariusz Gronczewski wrote: > 2012/3/21 Willy Tarreau <w...@1wt.eu>: > >> Can I do something to fix this? > > > > Krisztian Ivancso is working on FD passing between the old and the new > > process, which should catch most of these issues. The difficulty remains > > in identifying which FD can be reused and possibly adjusted when a number > > of options have been set (eg: MSS, interface binding, ...). > > > > In the mean time there is a kernel patch available on the site to enable > > SO_REUSE_PORT, which allows both processes to bind the port at the same > > time. It totally clears the uncertainty window since the new process binds > > and only then asks the other one to release the ports. But still there are > > a few RST left due to the half-open connections that cannot be transferred. > > > > Regards, > > Willy > > > > > There is "simple and ugly" hack for that, you can block sending RST > packets on iptables when restarting haproxy, that way clients who sent > SYN when haproxy port was down will just retransmit.
No, don't do that, it will not work and will be even worse. The RST is sent in response to the ACK, so with your hack, the client will infinitely retransmit the ACK. > Other way would be to start new haproxy copy on another port, do > iptables REDIRECT on it, then reload config on "main instance" and > remove REDIRECT, which would be even ugiler as you'd need 2 different > configs. There are people who proceed differently : - iptables -I INPUT -p tcp --dport $PORT --syn -j DROP - sleep 1 - service haproxy restart - iptables -D INPUT -p tcp --dport $PORT --syn -j DROP This has the effect of dropping the SYN before a restart, so that clients will resend this SYN until it reaches the new process. Regards, Willy
