Hi All, Sorry I missed it!!!! I'll see what I can do to fix it asap.
Thanks for reporting. Baptiste On Thu, Jan 26, 2017 at 6:40 PM, Lukas Tribus <lu...@gmx.net> wrote: > 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 > >
