Skip to content

Draft: [th/dns-resolved-default-route] dns: detect support of systemd-resolved's SetLinkDefaultRoute() and avoid it

Thomas Haller requested to merge th/dns-resolved-default-route into master

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? Would 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.

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

Also, detecting support is straight forward in the common case, where there is either success or a clearorg.freedesktop.DBus.Error.UnknownMethod error. In cases where there is any other failure, we don't really know. In that case, we still try to call the operations.

[1] https://github.com/systemd/systemd/commit/77673795dcf5797491e7f785cbf5077d29a15db4

I am not entirely convinced of this approach. It's a relatively complicated patch (*) with odd edge cases, if the detection does not succeed. But it's probably the best option.

(*) the level of complexity is still reasonable and not comparable to other, really complicated code under src/. You can review this code almost in isolation, and don't need to understand anything else about NetworkManager.

Merge request reports