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 790446 - NM resolved detection is incomplete
NM resolved detection is incomplete
Product: NetworkManager
Classification: Platform
Component: general
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Reported: 2017-11-16 14:09 UTC by Dimitri John Ledkov
Modified: 2017-11-19 13:59 UTC
See Also:
GNOME target: ---
GNOME version: ---

fix-resolved-detection.patch (937 bytes, patch)
2017-11-16 14:09 UTC, Dimitri John Ledkov
none Details | Review

Description Dimitri John Ledkov 2017-11-16 14:09:25 UTC
Created attachment 363835 [details] [review]

Sometimes the resolv.conf symlink is relative, rather than absolute. E.g. starts with ../run/ rather than /run. Thus the resolv.conf symlink target checks fail to detect resolved.

Also, v236 will introduce a new possible target for the file. It is already in use on Ubuntu. Thus I also extended the checks to trigger on that file too.

The basic idea / constants are shown in the patch attached, which could be applied as is - or reimplemented elsehow, if so desired.


Comment 1 Thomas Haller 2017-11-16 14:39:31 UTC

Can you explain why a relative path is used sometimes?


»···for (i = 0; i < G_N_ELEMENTS (RESOLVED_PATHS); i++) {
»···»···if (   stat (RESOLVED_PATHS[i], &st_test) == 0

you should not stat() relative paths. Or, if you really want to stat() them, then only after prepending "/etc/" to "../etc/pp". But maybe better just skip over them.

»···»···real_path = realpath (_PATH_RESCONF, NULL);
»···»···if (nm_utils_strv_find_first ((char **) RESOLVED_PATHS,
»···»···                              G_N_ELEMENTS (RESOLVED_PATHS),
»···»···                              real_path) >= 0)
relative paths will not match either, which is fine. But could you add a comment like:
   /* XXX: relative paths in RESOLVED_PATHS cannot match here */

(btw, please create patches with git-format-patch, preferably with a suitablecommit message, thanks!!)
Comment 2 Dimitri John Ledkov 2017-11-18 00:48:43 UTC
systemd-resolved supports for /etc/resolv.conf to be symlinked to one of three resolv.conf files it provides: two are dynamically generated, and one is shipped statically. Typically symlinks like these are created as relative paths e.g. ../usr/lib/systemd/resolv.conf, as can be seen in upstream systemd code...

And previous releases had the default to ../usr/lib/systemd/resolv.conf

I do not understand commments you make, imho it is ugly to repeat these paths as relative and absolute. Current detection is buggy, and doesn't detect correctly the cases when system is managed with resolved dns. Please fix that by comparing absolute targets of /etc/resolv.conf. And in case of pointing to dynamic paths, the files it points to may or may not be there yet on boot, as the /run files are only created after resolved is started. Sorry, I cannot provide a better patch for the currently buggy detection code.

Systemd itself, checks for inodes to detect if /etc/resolv.conf is managed by resolved or not. So maybe you can perform identical checks like here:
Comment 3 Thomas Haller 2017-11-19 13:59:46 UTC
patch merged:



> you should not stat() relative paths. Or, if you really want to stat() them, 
> then only after prepending "/etc/" to "../etc/pp". But maybe better just skip 
> over them.

done too: