GNOME Bugzilla – Bug 790446
NM resolved detection is incomplete
Last modified: 2017-11-19 13:59:46 UTC
Created attachment 363835 [details] [review] fix-resolved-detection.patch 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. Regards, Dimitri.
Hi, Can you explain why a relative path is used sometimes? In »···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. in, »···»···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!!)
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... https://github.com/systemd/systemd/blob/master/tmpfiles.d/etc.conf.m4#L17 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: https://github.com/systemd/systemd/blob/master/src/resolve/resolved-resolv-conf.c#L34
patch merged: master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=e09503dcc43039905018b26304bfe94287211aa6 nm-1-10: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=4d77df775195e78eae144ad26bee1d312201a88c > 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: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=25267f9d274f93c57b051eca607096ac0c28b4b4 Thanks