|
I meant that I will NOT try to upstream the custom patch I intend to make (sorry for the typo :p )
From: networkmanager-list <networkmanager-list-bounces gnome org> on behalf of Frederic Martinsons <frederic martinsons sigfox com>
Sent: Friday, October 30, 2020 4:26 PM To: Thomas Haller <thaller redhat com>; networkmanager-list gnome org <networkmanager-list gnome org> Subject: Re: Question about DNS managemer lifecycle
Ok thanks Thomas for the quick answer.
I'm not feeling ready for a big dev in NM adding support for dnsmasq as an external service.
Moreover, we had already investigated about systemd-resolved but our particular use cases , it is not fitted.
I think I'll do a custom patch (of course I'll try to upstream this) of NM that will stop DNS plugin inside nm_dns_manager_stop.
But a question remains , is it normal that ref count of NMManager is still 3 at the end of main ? I spent 2 days trying to track objects lifecycle
but I gave up on this.
Thanks again for your help
From: Thomas Haller Sent: Friday, October 30, 2020 4:02 PM To: Frederic Martinsons; networkmanager-list gnome org Subject: Re: Question about DNS managemer lifecycle On Fri, 2020-10-30 at 13:45 +0000, Frederic Martinsons wrote:
> Hello NM hackers, > > I'm tracking a nasty bug in dnsmasq (possibly introduced by us > because of patches) and it is triggered during shutdown (while > systemd stop all services). > > Tracking this, I activated traces of NetworkManager and it seems that > dnsmasq (the dns manager I used) is not stopped by NetworkManager. I > patched NM to print refcount of all objects and I see that > NMDnsManager has refcount at 2 after calling nm_dns_manager_stop in > main.c. > > I would like to have information about DNS manger lifecycle since I > see a comment in NM merge requests which seem telling that it may be > done on purpose (to not stop dnsmasq) , I'm talking about the > following comment: > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/254#note_217659 > > By the way, I use NetworkManager 1.26.4 and dnsmasq 2.82. > > Thank you very much for any help you can provide. Hi, when restarting (or only stopping) NetworkManager, it leaves the interfaces up, in an attempt not to disrupt your connectivity. So, there is a point in leaving the dnsmasq instance running. Restarting NetworkManager (with it's aim to not disrupt connectivity) has many coerner cases where it doesn't work overly well. So restarting NetworkManager should not be done on a regular basis. Leaving the dnsmasq instance running can be problematic, because after restart the dnsmasq instance is no longer a child process (we cannot waitpid on it). Also, in general it might be undesirable. On the other hand, stopping NetworkManager and breaking DNS is also undesirable. The code, and in particular commit [1] makes an effort to get that right. But it's not entirely clear whether the dnsmasq instance should be left running or not. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/254/diffs?commit_id=a780b04837f444c9dbb63d48442c78e3cc4dcfe9 If you find a bug, we would gladly accept patches. As to what is the optimal/desired behahavior, that is up for discussion. A better solution would be to extend "dns=dnsmasq" option to run the dnsmasq instance as a separate service (which would work well when using systemd, but it might be harder on systems without systemd). It not likely that somebody invests the effort of improving dns=dnsmasq, especially since an improved DNS plugin already exists: systemd-resolved. best, Thomas |