On Mon, 10 Mar 2025 at 09:17, Luke Seelenbinder <luke.seelenbin...@stadiamaps.com> wrote: > > Hi Willy, > > > On Mar 10, 2025, at 15:12, Willy Tarreau <w...@1wt.eu> wrote: > > > > Hi Luke, > > > > On Mon, Mar 10, 2025 at 12:54:51PM +0700, Luke Seelenbinder wrote: > >> Hi all, > >> > >> Thanks for confirming it should work--based on the feedback, we realized > >> the > >> issue is actually not with `nameservers`, but on startup, so this is > >> actually > >> init-addr taking precedence. We missed that in the initial analysis. > >> > >> Our init-addr is `init-addr libc,last,none`. Due to a complex set of > >> factors, > >> using libc to resolve a host can simply hang, instead of fail. When HAProxy > >> starts up and libc hangs, the startup times out instead of failing with no > >> IP > >> (i.e. `none`). > > > > Ah OK makes sense. That said, if a regular server does not resolve, > > normally it doesn't boot. You mean that here it still boots with no > > address ? > > No, that's the problem; we'd prefer HAProxy to have no IP for a server at > boot than to fail to boot, but since libc just hangs instead of failing, it > doesn't finish booting, and the startup times out. This ends up creating a > service restart cycle. > > This means the docs are slightly misleading, however? Since `init-addr > libc,last,none` results in a hang if libc just hangs vs failing. I don't know > if a hard or configurable timeout on the underlying call makes sense?
It's a blocking syscall, I don't think there is anything that can be done about it. Your use case matches "init-addr none" (or last,none): only the haproxy resolver will be used, haproxy will not refuse to start and will not depend on libc name resolution. Mixing libc and resolver resolution is imo always dangerous. libc resolution can hide resolver issues, which than become harder to diagnose and vice versa. But libc based name resolution behavior itself is never up to haproxy, but OS/libc configuration. Lukas
