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. Regards, Willy
