GNOME Bugzilla – Bug 760691
NM keeps trying to restart failing DNS plugins
Last modified: 2016-01-21 09:47:51 UTC
If dnsmasq (or another DNS plugin) exits immediately (for example due to an already used port), the DNS manager keeps restarting it forever, wasting system resources and filling logs. ... 15:07:21 <info> DNS: starting dnsmasq... 15:07:21 dnsmasq: failed to create listening socket for 127.0.0.1: Address already in use 15:07:21 <warn> dnsmasq exited with error: Network access problem (address in use; permissions; etc) (2) 15:07:21 <warn> DNS: plugin dnsmasq child quit unexpectedly; refreshing DNS 15:07:21 <info> DNS: starting dnsmasq... 15:07:21 dnsmasq: failed to create listening socket for 127.0.0.1: Address already in use 15:07:21 <warn> dnsmasq exited with error: Network access problem (address in use; permissions; etc) (2) 15:07:21 <warn> DNS: plugin dnsmasq child quit unexpectedly; refreshing DNS 15:07:21 <info> DNS: starting dnsmasq... 15:07:21 dnsmasq: failed to create listening socket for 127.0.0.1: Address already in use 15:07:21 <warn> dnsmasq exited with error: Network access problem (address in use; permissions; etc) (2) 15:07:21 <warn> DNS: plugin dnsmasq child quit unexpectedly; refreshing DNS ....
Created attachment 319154 [details] [review] [PATCH] dns-manager: prevent DNS plugins from respawning too quickly
I think that for g_child_watch_add() we should not call g_source_remove() inside the callback. - nm_clear_g_source (&priv->watch_id); + priv->watch_id = NULL; Isn't the change to watch_cb() an unrelated bugfix? Maybe move it to a separate patch? nm_utils_get_monotonic_timestamp_ms() returns (signed) gint64 because that plays better when diffing two timestamps (so that you get a negative value, when the subtrahend is in the future). Lets have the data type for "ts" consistent as signed too. otherwise, lgtm
(In reply to Thomas Haller from comment #2) > I think that for g_child_watch_add() we should not call g_source_remove() > inside the callback. > > - nm_clear_g_source (&priv->watch_id); > + priv->watch_id = NULL; > > Isn't the change to watch_cb() an unrelated bugfix? Maybe move it to a > separate patch? There wasn't a real bug before because the watch callback emitted a signal which caused a restart of the plugin and thus a clear of the source. So let's consider this a consequence of the rework. > nm_utils_get_monotonic_timestamp_ms() returns (signed) gint64 because that > plays better when diffing two timestamps (so that you get a negative value, > when the subtrahend is in the future). Lets have the data type for "ts" > consistent as signed too. Fixed and applied to master: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=64ac9101316471cce38f360d438dd8f948de6dcb