FS#62138 - [networkmanager] NetworkManager keeps asking for org.freedesktop.resolve1

Attached to Project: Arch Linux
Opened by Bachsau (Bachsau) - Monday, 25 March 2019, 17:41 GMT
Last edited by Toolybird (Toolybird) - Monday, 29 May 2023, 03:38 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Jan Alexander Steffens (heftig)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
Even though main.dns is set to default in NetworkManagers configuration file, it keeps requesting org.freedesktop.resolve1:

Mar 25 18:34:34 BachsauDesk dbus-daemon[614]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.15' (uid=0 pid=616 comm="/usr/bin/NetworkManager --no-daemon ")
Mar 25 18:34:34 BachsauDesk dbus-daemon[614]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.

Since then, connections to SFTP servers by GVFS don't work anymore.
This seems closely related to  FS#49142  and  FS#54530 .
This task depends upon

Closed by  Toolybird (Toolybird)
Monday, 29 May 2023, 03:38 GMT
Reason for closing:  No response
Additional comments about closing:  Plus it's old and stale. If still an issue, please report upstream.
Comment by Bachsau (Bachsau) - Monday, 25 March 2019, 17:54 GMT
There is also a bug report for this in systemd:  FS#61738 
Comment by Jake Kreiger (Magali75) - Monday, 25 March 2019, 21:54 GMT
You may try adding "systemd-resolved=false" to /etc/NetworkManager/NetworkManager.conf
Comment by Bachsau (Bachsau) - Tuesday, 26 March 2019, 02:49 GMT
Don't you think that this should be the default, when "dns" is "default"? I understand there are some rare use-cases, but most of the time, when "dns" has been set to "default", it means that systemd-resolved is disabled and should not be used.

Either way, it helped in that NetworkManager stopped spamming my log files. Unfornately, it didn't solve my probems with GVFS though. Either that is just an interely differend problem, or the now removed service did something GFVS and VPNC dependet on, even when systemd-resolved was disabled. Would that be possible?
Comment by nl6720 (nl6720) - Tuesday, 26 March 2019, 06:28 GMT
main.systemd-resolved=false is the upstream's default. See https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d4eb4cb45f41b1751cacf71da558bf8f0988f383 .

The message in journal is likely because there's no "/usr/lib/systemd/system/dbus-org.freedesktop.resolve1.service -> systemd-resolved.service" symlink. If there was, then NetworkManager would activate systemd-resolved (which might not be desired by the user and could have a large effect due to "resolve" being before "dns" in /etc/nsswitch.conf)
Comment by Jake Kreiger (Magali75) - Tuesday, 26 March 2019, 12:46 GMT
@nl6720 I think you misread something. The default is "true":

<literal>systemd-resolved</literal>. Defaults to "<literal>true</literal>".

In commit message upstream tells to use false if needed:

"If for whatever reasons don't want NetworkManager to push the DNS data
it discovers to systemd-resolved, the functionality can be disabled
with:

[main]
systemd-resolved=false"

@Bachsau if it doesn't fix your problem then it seems unrelated to this.
Comment by nl6720 (nl6720) - Tuesday, 26 March 2019, 13:05 GMT
Sorry. I meant that main.systemd-resolved=true is the upstream's default. I was too lazy to type the option out so I copied it from somewhere without reading it.
Comment by physkets (physkets) - Friday, 27 September 2019, 16:26 GMT
NetworkManager would never finish making my Ethernet connection unless I restarted the service. Setting resolved to false in the .conf file solved the problem for me. This is a serious issue if it is happening to more people. (I'm using DNSCrypt-proxy - that could be why I had this problem)
Comment by mattia (nTia89) - Saturday, 19 March 2022, 11:06 GMT
This is a very old issue. Is it still valid for you with latest version?

Loading...