[kawsper]

Oh, you are right, after searching a little on the subject it looks like some people are doing things like this:

    iptables -I INPUT -p tcp -m multiport —dports 80,443 —syn -j DROP && sleep 0.5 && \
    /etc/init.d/haproxy reload;
    iptables -D INPUT -p -tcp -m multiport —dports 80,443 —syn -j DROP

Source: https://medium.com/@Drew_Stokes/actual-zero-downtime-with-ha...

[coops]

I feel I must point out that this relies on your clients to retry packets that iptables drops, so at the least they'll have a slower experience than they otherwise would. I believe that this will also break requests that are in flight when the reload happens, if they have sent partial data.

[kawsper]

Yeah, it feels like a dirty, dirty hack. The way I understood it is that the requests in flight would retry the same way as the new connections when the first iptables rule is applied.

[coops]

I think what will actually happen to requests in flight is:

- partial data received by old HAProxy is lost as old HAProxy exits

- new HAProxy comes online, binds to port, receives fd

- iptables rule removed. new HAProxy starts receiving new requests

- in-flight requests from the old HAProxy are timed out by the kernel (TCP RST) as nothing is there to read request data from the old fd or send response data.

So I think this is actually "worse" in some sense than the other retry behavior since it's not recovered inside the same TCP session but instead forces the client to open a new TCP session.