dns: detect support of systemd-resolved's SetLinkDefaultRoute() and avoid it

We now always use SetLinkDefaultRoute(), but that API was only added in
systemd v240 ([1]).

We could just always call the non-existing method, and ignore the
error. However, that feels ugly. Would systemd-resolved log warnings
about that? Should we suppress all messages about that failure (not
good for debugging).

Instead, make an effort to detect support of the function, and avoid
calling it. That is significantly more complicated than just always
calling the method and not care.

Note that even if systemd-resolved does not support SetLinkDefaultRoute(),
we cannot do anything smart about that. We would simply rely on
systemd-resolved (hopefully) doing the right thing automatically.
That's better and simpler than explicitly adding a "~." domain in
the fallback case.

Also, detecting support is straight forward in the common case, where
there is either success or a clear "org.freedesktop.DBus.Error.UnknownMethod"
error. In cases where there is any other failure, we don't really know.
In that case, we keep trying to use the API under the assumption that
it should work.

[1] https://github.com/systemd/systemd/commit/7 ## 7673795dcf5797491e7f785cbf5077d29a15db4
This commit is contained in:
Thomas Haller
2020-11-25 17:27:04 +01:00
parent 4fc44952f7
commit 44ebb99cfa

View File

@@ -65,6 +65,7 @@ typedef struct {
bool dbus_has_owner : 1;
bool dbus_initied : 1;
bool request_queue_to_send : 1;
NMTernary has_link_default_route : 3;
} NMDnsSystemdResolvedPrivate;
struct _NMDnsSystemdResolved {
@@ -144,17 +145,29 @@ call_done(GObject *source, GAsyncResult *r, gpointer user_data)
priv = NM_DNS_SYSTEMD_RESOLVED_GET_PRIVATE(self);
if (v) {
if (request_item->operation == DBUS_OP_SET_LINK_DEFAULT_ROUTE
&& priv->has_link_default_route == NM_TERNARY_DEFAULT) {
priv->has_link_default_route = NM_TERNARY_TRUE;
_LOGD("systemd-resolved support for SetLinkDefaultRoute(): API supported");
}
priv->send_updates_warn_ratelimited = FALSE;
return;
}
log_level = LOGL_DEBUG;
if (request_item->operation == DBUS_OP_SET_LINK_DEFAULT_ROUTE
&& nm_g_error_matches(error, G_DBUS_ERROR, G_DBUS_ERROR_UNKNOWN_METHOD)) {
if (priv->has_link_default_route == NM_TERNARY_DEFAULT) {
priv->has_link_default_route = NM_TERNARY_FALSE;
_LOGD("systemd-resolved support for SetLinkDefaultRoute(): API not supported");
}
return;
}
log_level = LOGL_DEBUG;
if (!priv->send_updates_warn_ratelimited) {
priv->send_updates_warn_ratelimited = TRUE;
log_level = LOGL_WARN;
}
_NMLOG(log_level,
"send-updates %s@%d failed: %s",
request_item->operation,
@@ -364,6 +377,15 @@ send_updates(NMDnsSystemdResolved *self)
priv->request_queue_to_send = FALSE;
c_list_for_each_entry (request_item, &priv->request_queue_lst_head, request_queue_lst) {
if (request_item->operation == DBUS_OP_SET_LINK_DEFAULT_ROUTE
&& priv->has_link_default_route == NM_TERNARY_FALSE) {
/* The "SetLinkDefaultRoute" API is only supported since v240.
* We detected that it is not supported, and skip the call. There
* is no special workaround, because in this case we rely on systemd-resolved
* to do the right thing automatically. */
continue;
}
/* Above we explicitly call "StartServiceByName" trying to avoid D-Bus activating systmd-resolved
* multiple times. There is still a race, were we might hit this line although actually
* the service just quit this very moment. In that case, we would try to D-Bus activate the
@@ -478,7 +500,8 @@ name_owner_changed(NMDnsSystemdResolved *self, const char *owner)
if (owner) {
priv->try_start_blocked = FALSE;
priv->request_queue_to_send = TRUE;
}
} else
priv->has_link_default_route = NM_TERNARY_DEFAULT;
send_updates(self);
}
@@ -551,6 +574,8 @@ nm_dns_systemd_resolved_init(NMDnsSystemdResolved *self)
{
NMDnsSystemdResolvedPrivate *priv = NM_DNS_SYSTEMD_RESOLVED_GET_PRIVATE(self);
priv->has_link_default_route = NM_TERNARY_DEFAULT;
c_list_init(&priv->request_queue_lst_head);
priv->dirty_interfaces = g_hash_table_new(nm_direct_hash, NULL);