After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 779269 - DNS info not pushed to systemd-resolved if /etc/resolv.conf is a relative symlink
DNS info not pushed to systemd-resolved if /etc/resolv.conf is a relative sym...
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: general
1.6.x
Other Linux
: Normal minor
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2017-02-26 19:54 UTC by Sam Morris
Modified: 2017-05-13 15:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sam Morris 2017-02-26 19:54:26 UTC
I found that NM wasn't talking to systemd-resolved because I have:

$ readlink /etc/resolv.conf
../run/systemd/resolve/resolv.conf

Once I changed the symlink target to use an absolute path, NM correctly started pushing DNS server info to systemd-resolved.

The following Python code will resolve the symlink with glib. If you think it is sane, I can send a patch to make the _resolvconf_resolved_managed function do the same.

>>> from io.repository import Gio
>>> f = Gio.File.new_for_path('/etc/resolv.conf')
>>> i = query_info(Gio.FILE_ATTRIBUTE_STANDARD_IS_SYMLINK + ',' + Gio.FILE_ATTRIBUTE_STANDARD_SYMLINK_TARGET, Gio.FileQueryInfoFlags.NOFOLLOW_SYMLINKS, None)
>>> f.get_parent().resolve_relative_path(i.get_symlink_target()).get_path()
'/run/systemd/resolve/resolv.conf'

Alternatively, the wording in the documentation could make it clear that systemd-resolved only becomes the default dns backend if /etc/resolv.conf is a symlink that points to networkd's resolv.conf file as an absolute path.
Comment 1 Beniamino Galvani 2017-02-27 13:28:50 UTC
(In reply to Sam Morris from comment #0)
> I found that NM wasn't talking to systemd-resolved because I have:
> 
> $ readlink /etc/resolv.conf
> ../run/systemd/resolve/resolv.conf
> 
> Once I changed the symlink target to use an absolute path, NM correctly
> started pushing DNS server info to systemd-resolved.
> 
> The following Python code will resolve the symlink with glib. If you think
> it is sane, I can send a patch to make the _resolvconf_resolved_managed
> function do the same.

Yes please, I think we should consider the absolute path when comparing the link.
Comment 2 Sam Morris 2017-02-27 19:37:54 UTC
While working on this I realised that it's easier to simply stat /etc/resolv.conf, and compare its st_dev and st_ino to those of each of the resolved_paths until we get a match. This way the kernel takes care of resolving the symlinks for us.

I've submitted a pull request on Github: https://github.com/NetworkManager/NetworkManager/pull/16

The same comparison can be performed using gio, but it's a lot more complex: https://github.com/NetworkManager/NetworkManager/compare/master...yrro:networkd-resconf-fileid
Comment 3 andysem 2017-05-10 18:20:56 UTC
I think, this bug affects me as well on Kubuntu 17.04, NetworkManager 1.4.4. I have an OpenVPN connection with a static DNS IP and search domain specified in the connection settings. Sometimes (in ~50% cases) these settings are not forwarded to systemd-resolved when the connection is established. /etc/resolv.conf is a symlink to ../run/resolvconf/resolv.conf.
Comment 4 Thomas Haller 2017-05-11 12:00:27 UTC
The detection of systemd-networkd was improved:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=fae84b16f850c8a9d6a5f5c4bee1c162debb8dec


Note, that as workaround, you can always explicitly configure the dns-plugin via

[main]
dns=systemd-resolved

(but of course, detection based on the symlink is better).
Comment 5 andysem 2017-05-12 12:02:14 UTC
Setting "dns=systemd-resolved" does not help. I still sometimes get DNS params not pushed to systemd-resolved after the VPN connection is established.
Comment 6 Thomas Haller 2017-05-13 15:03:02 UTC
(In reply to andysem from comment #5)
> Setting "dns=systemd-resolved" does not help. I still sometimes get DNS
> params not pushed to systemd-resolved after the VPN connection is
> established.

then your issue is not the same as this bug.