Could it be some kind of workaround to use another instance as broker and starting the "real" haproxy twice with some ENV-Var to bind a the frontends/listeners to sockets instead of directly listing on the servers ip? I think of something like: a) haproxy A - acting as some kind of broker, binding to the servers ips with a really simple configuration and a TCP-listener - this "haproxy-broker" would not "ever" need a reload/restart b) haproxy B + haproxy C using the exact same configuration and binding a frontend to a socket like /var/run/haproxy-$ENVVAR (so it would be /var/run/haproxy-B und /var/run/haproxy-C
Now you set one of B or C to maintenance and only use the other. If you have to reload 'cause of configuration changes you would only reload/restart the "inactive" instance - setting it active afterwards in haproxy-broker and DRAIN/MAINT the other instance What do you think? Tim -----Ursprüngliche Nachricht----- Von: Willy Tarreau [mailto:[email protected]] Gesendet: Dienstag, 9. August 2016 19:38 An: Aleksandar Lazic Cc: Lukas Tribus; [email protected] Betreff: Re: SYN dropping at reload time On Tue, Aug 09, 2016 at 05:06:15PM +0200, Aleksandar Lazic wrote: > > > Am 09-08-2016 17:03, schrieb Lukas Tribus: > > Am 09.08.2016 um 16:39 schrieb Aleksandar Lazic: > > > > > > > On Linux yes, because there is a race condition: > > > > > > > > http://lwn.net/Articles/542866/ > > > > http://engineeringblog.yelp.com/2015/04/true-zero-downtime-hapro > > > > xy-reloads.html > > > > > > Thanks. > > > > > > So every Software on Linux should have this issue right? > > > > > > I'm one of the lucky person who have not faced this problem ;-). > > > > > > But the same issue can happen with nginx, apache httpd, uwsgi, and > > > so on also, right. > > > > That depends on the situation. > > > > Nginx uses a master and worker processes for example. If you only > > change the configuration, the master process may not get restarted > > (only workers are restarted), so the race is irrelevant. How exactly > > nginx handles the binary upgrade on Linux - I don't know. > > Yes that's true. that's a different concept. Note that it's not a matter of process but of socket. In SO_REUSEPORT mode we have multiple sockets for a same ip:port. So packets are delivered into individual sockets. When the last user of a socket closes it, the socket is closed, and a reset is sent for all packets in its queue. The only way to avoid this would be to have a master/worker model where the master is never restarted, deals with sockets and passes them to the other processes over unix sockets. A first step for this was developped by Simon a few years ago but he probably faced all the architecture limitations at once, resulting in various stuff like segfaults on reloads and I don't remember what! The exact model needed in fact is not a master/worker but a socket server (which the master often is in such a model). But to a certain extent we could very well imagine an external process used as a socket server and being reconfigured upon every reload, delivering sockets and keeping refcounts on them. This is something that could be worth reconsidering for 1.8 if people are willing to work on this, but it's a huge effort due to a lot of history accumulated in this dirty area to be honnest. Willy
