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
