On Tue, Jan 31, 2017 at 2:14 AM, Willy Tarreau <[email protected]> wrote: > Hi Baptiste, > > On Mon, Jan 30, 2017 at 11:07:53PM +0100, Baptiste wrote: > > Hi all, > > > > Please find attached a patch to fix the issue reported by Joshua on the > ML > > and sjiveson on discourse. > > I moved the initialisation of the dns_resolvers() after the fork. I can > > confirm now than each process has its own UDP socket to send DNS > requests. > > Thanks for doing this. I think that for stable versions it's perfect. > However calling dns_init_resolvers() after the fork also means we've > closed the stderr and detached the processes so we'll never get the > possible errors. I've checked and the function above deals with two > types of errors : > > - memory allocation issues (OK, rare enough) > > - network issues (eg: missing route causing connect() to fail) > This last one is more problematic because it will cause all the > processes to silently quit just after forking when the init > scripts says "OK", which is pretty bad. > > I'd really like that for the mid-term we can have a different method, > consisting in this : > > - running dns_init_resolvers() as it is today, before the fork(). This > way we're certain that the config is OK. > > - just after the fork(), simply walk over all resolvers, close and > reopen the sockets (thus perform a small part of dns_init_resolvers() > again) so that each process has its own socket. We're doing this > already for epoll. > > Alternatively, we can decide that dns_init_resolvers() creates enough > sockets for all processes and keeps them available, then closes the > unneeded ones after the fork, but that's in fact trickier in my opinion. > > If you see how to implement something like what is described above, I > can wait a bit more for a better fix. If you're facing difficulties, > I can merge it now as a temporary fix. Just let me know. > > Thanks! > Willy >
Understood. Let's use this Sunday as a dead line. I think I can make dns_init_resolvers() to take an argument 'int close_socket' whose value could be 0 or 1. If 1, then HAProxy will try to close the socket before re-opening it. if 0, then it simply tries to open the socket. Until this new patch is available, people needing DNS and multiprocess can use the first patch. Baptiste
