Hello,
Am 29.11.2016 um 09:53 schrieb Willy Tarreau:
Hi Joshua,
[ccing Baptiste]
On Tue, Nov 29, 2016 at 02:17:17AM -0500, Joshua M. Boniface wrote:
Hello list!
I believe I've found a bug in haproxy related to multiproc and a set of DNS
resolvers. What happens is, when combining these two features (multiproc and
dynamic resolvers), I get the following problem: the DNS resolvers, one per
process it seems, will fail intermittently and independently for no obvious
reason, and this triggers a DOWN event in the backend; a short time later,
the resolution succeeds and the backend goes back UP for a short time, before
repeating indefinitely. This bug also seems to have a curious effect of
causing the active record type to switch from A to AAAA and then back to A
repeatedly in a dual-stack setup, though the test below shows that this bug
occurs in an IPv4-only environment as well, and this failure is not
documented in my tests.
(...)
I've just taken a quick look at how the socket is created and I understand
the issue you're facing. The socket is created before the fork, so all
processes share the same socket, and responses can be sent to processes
which did not emit the request. We'll have to change this (I don't know
how for now) so that each process has its own socket. We do the same for
the epoll FD after fork.
I think that we should keep this initialization where it is as it is
able to spot config issues, and just close these sockets and reopen
them after fork, keeping fingers crossed for a new error not happening
right after fork(). BTW, by analogy with what is done with peers or
even regular servers, we should probably only create the socket when
needed and simply report socket creation errors in the logs.
Another option would be to create many sockets and later close them but
that's ugly and more complicated.
In the mean time the best thing to do will be to disable multi-proc with
DNS.
FYI, this was just reported on discourse as well:
http://discourse.haproxy.org/t/dns-resolution-sigh-v1-7-1/960/2
cheers,
lukas
