Hello Dominik, you are looking for hard-stop-after:
http://cbonte.github.io/haproxy-dconv/2.2/configuration.html#hard-stop-after Regards, Lukas On Thu, 4 Feb 2021 at 11:40, Froehlich, Dominik <[email protected]> wrote: > > Hi, > > > > I am currently experimenting with the HAproxy soft reload functionality (USR2 > to HAproxy master process). > > From what I understood, a new worker is started and takes over the listening > sockets while the established connections remain on the previous worker until > they are finished. > > The worker then terminates itself once all work is done. > > > > I’ve noticed there are some quite long-lived connections on my system (e.g. > websockets or tcp-keepalive connections from slow servers). So when I am > doing the reload, the previous instance > > of HAproxy basically lives as long as the last connection is still going. > Which potentially could go on forever. > > > > So when I keep reloading HAproxy because the config has changed, I could end > up with dozens, even hundreds of HAproxy instances running with old > connections. > > > > My question: Is there a way to tell the old haproxy instances how much time > they have to get done with their work and leave? > > I know it’s a tradeoff. I want my users to not be disrupted in their > connections but I also need to protect the ingress machines from overloading. > > > > Any best practices here? > > > > Cheers, > > D
