Re: Question about DNS managemer lifecycle

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:
> By the way, I use NetworkManager 1.26.4 and dnsmasq 2.82.
> Thank you very much for any help you can provide.


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.


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:


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]