On 08/11/2015 04:14 AM, Simon Kelley wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > > On 10/08/15 22:29, Laine Stump wrote: >> On 08/10/2015 01:08 PM, Maxim Perevedentsev wrote: >>> This is a fix for commit >>> db488c79173b240459c7754f38c3c6af9b432970 dnsmasq main process >>> exits without waiting for DAD, this is dnsmasq daemon's task. So >>> we periodically poll the kernel using netlink and check whether >>> there are any IPv6 addresses assigned to bridge which have >>> 'tentative' state. After DAD is finished, execution continues. I >>> guess that is what dnsmasq was assumed to do. >> Since the comments in our code imply that dnsmasq should be waiting >> for DAD to complete prior to daemonizing, before pushing a fix like >> this I'd like to find out from the dnsmasq folks if we are >> erroneously relying on nonexistent dnsmasq behavior, or if maybe >> there is a bug in some version of dnsmasq. >> >> Simon (or other dnsmasq people) - when dnsmasq is run with >> "enable-ra", does it make sure it completes DAD prior to >> daemonizing? Or does libvirt need to do this extra polling to >> assure that DAD has completed? (or maybe there's some other config >> parameter we need to add?) >> >> > Dnsmasq doesn't wait for DAD to complete before returning. Internally, > it know is DAD is still happening on an interface, as it needs to > delay calling bind() until after it's complete. It would, therefore be > relatively simple to add this behaviour, but it's not a complete > solution, since new interfaces can appear _after_ dnsmasq has > completed start-up. > > Having libvirt do its own checks whenever it creates an interface > might therefore be a cleaner way of doing things, but I don't have an > objection to changing dnsmasq behaviour if there's a good reason why > that's not sensible. No need for dnsmasq to change its behavior. I just wanted to make sure that it was the comment in libvirt that was wrong, and not a regression in dnsmasq. Based on your answer, it appears that this was a misunderstanding by the original author of the libvirt code, so it is something that libvirt needs to fix. Thanks for the quick response! -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list