Re: Feature suggestion: Check for same binding on multiple frontends
Hello, On 8 March 2018 at 06:36, Moomjian, Chadwrote: > Thanks for the information, Lukas. I'm confused why this is not a default > option though. Can you think of a time when you would ever want the exact > same binding in multiple places in the config? noreuseport is not something that reads the configuration and applies some kind of heuristics for such errors, what it does is that it makes haproxy NOT set the SO_REUSEPORT [1] socket option. SO_REUSEPORT is useful because it permits faster and (depending on more factors) hitless reloads. Other than that an important use-case is to have the kernel load-balance between different sockets on different CPU cores for scalability reasons. Lukas [1] https://lwn.net/Articles/542629/
RE: Feature suggestion: Check for same binding on multiple frontends
Thanks for the information, Lukas. I'm confused why this is not a default option though. Can you think of a time when you would ever want the exact same binding in multiple places in the config? -Original Message- From: lu...@ltri.eu [mailto:lu...@ltri.eu] Sent: Wednesday, March 7, 2018 3:21 AM To: Moomjian, Chad <cmoomj...@outmatch.com> Cc: haproxy@formilux.org Subject: Re: Feature suggestion: Check for same binding on multiple frontends Hello Chad, On 7 March 2018 at 03:34, Moomjian, Chad <cmoomj...@outmatch.com> wrote: > Haproxy Developers, > > > > I recently modified a configuration file for haproxy, and after > setting it up, I noticed that about half of my requests came back with > a 503 error, and the other half came back with the correct elements being > returned. > > > > After doing troubleshooting involving a test haproxy instance and > changing the IP address, I realized that I had mistakenly added the > same IP binding, 10.x.x.11:443, in two different frontends. As a > result, half of my requests had no matching path (we don’t use a > default backend), and the other half were using responding correctly. > > > > Since I cannot think of a time when this would be desired behavior, > would it be possible to add a check on haproxy startup for the exact > same IP binding in multiple frontends of the same config file? This > could save me and others from possibly making this mistake in the future. You can set noreuseport in the global section to guarantee that there is only a single socket bound to a port: http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.2-noreuseport Lukas
Re: Feature suggestion: Check for same binding on multiple frontends
Hello Chad, On 7 March 2018 at 03:34, Moomjian, Chadwrote: > Haproxy Developers, > > > > I recently modified a configuration file for haproxy, and after setting it > up, I noticed that about half of my requests came back with a 503 error, and > the other half came back with the correct elements being returned. > > > > After doing troubleshooting involving a test haproxy instance and changing > the IP address, I realized that I had mistakenly added the same IP binding, > 10.x.x.11:443, in two different frontends. As a result, half of my requests > had no matching path (we don’t use a default backend), and the other half > were using responding correctly. > > > > Since I cannot think of a time when this would be desired behavior, would it > be possible to add a check on haproxy startup for the exact same IP binding > in multiple frontends of the same config file? This could save me and others > from possibly making this mistake in the future. You can set noreuseport in the global section to guarantee that there is only a single socket bound to a port: http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.2-noreuseport Lukas