Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#61738 - [openconnect] Unit dbus-org.freedesktop.resolve1.service not found.

Attached to Project: Arch Linux
Opened by f (bakgwailo) - Wednesday, 13 February 2019, 01:22 GMT
Last edited by David Runge (dvzrv) - Friday, 17 January 2020, 11:09 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 15
Private No

Details

Description:

Noticed after updating my system today and rebooting my openconnect VPN was no longer working. Further investigation shows systemd-resolve status fails with this error message:

status: resolve call failed: Unit dbus-org.freedesktop.resolve1.service not found.

Additional info:
* package version(s)

systemd 240.95-1

Normal/up to date Arch, no testing repos enabled.

Steps to reproduce:

Run systemd-resolve (or I guess anything else that depends on it like openconnect).
This task depends upon

Comment by f (bakgwailo) - Wednesday, 13 February 2019, 01:28 GMT
Just as a note - I did systemctl enable systemd-resolved.service and it seemed to resolve the issue with systemd-resolve. Not sure why it was disable on upgrade.
Comment by Ryan Alberts (ralberts) - Wednesday, 13 February 2019, 04:18 GMT
Thank you! I just ran into this tonight and super thankful this came up on google! Doing the above command worked for me as well!
Comment by Matthew Hiles (zashi) - Thursday, 21 February 2019, 16:55 GMT
I am also hitting this. I do not normally use systemd-resolve I prefer openresolv. The two are mutually exclusive. Is there no way to make this work without installing and using systemd-resolve?
Comment by loqs (loqs) - Thursday, 21 February 2019, 18:28 GMT
@zashi I think http://git.infradead.org/users/dwmw2/vpnc-scripts.git/blob/07c3518dd6b8dc424e9c3650a62bed994a4dcbe1:/vpnc-script#l119
as used by vpnc 1:0.5.3.r454.r67-1 needs adjustment although that seems to be a separate issue to why systemd-resolve was disabled on upgrade.
Edit:
changed line number from 131 to 119
Comment by John Henderson (jwhendy) - Monday, 25 February 2019, 17:41 GMT
I just ran into this as well, but enabling systemd-resolved was not sufficient. I'm getting additional errors like:
- Error: any valid prefix is expected rather than "dev"
- RTNETLINK answers: File exists (after a Ctrl-C and 2nd attempt to openconnect)

I still get the "dev" error, but by checking my ifconfig output after vpn, I could put the real nameserver in /etc/resolv.conf and all is working (it was some 192.168.foo after connecting).
Comment by Matthew Hiles (zashi) - Monday, 25 February 2019, 17:46 GMT
Uninstalling systemd-resolve and downgrading systemd to 240... from 241... resolved my issue.
Comment by John Henderson (jwhendy) - Monday, 25 February 2019, 17:53 GMT
@Matthew Hiles: uninstalling systemd-resolve == `systemctl disable systemd-resolved`? I tried downgrading to 240 this morning (and to kernel 4.20.8 from 4.20.11 for the heck of it), but had the same results.
Comment by Matthew Hiles (zashi) - Monday, 25 February 2019, 17:58 GMT
I don't like systemd resolve. I mean Pacman -R uninstall. Everything went back to working The way it had prior to my last update.
Comment by loqs (loqs) - Monday, 25 February 2019, 17:59 GMT
@jwhendy what do you want to control /etc/resolv.conf on your system if anything?
Comment by John Henderson (jwhendy) - Monday, 25 February 2019, 18:00 GMT
@Matthew Hiles: I guess I don't follow, then.

$ pacman -Qo /usr/lib/systemd/system/systemd-resolved.service
/usr/lib/systemd/system/systemd-resolved.service is owned by systemd 241.7-2

You uninstalled all of systemd?
Comment by Matthew Hiles (zashi) - Monday, 25 February 2019, 19:23 GMT
Sorry, I was working from memory and working from anything that unreliable is going to be garbage.

I uninstalled *systemd-resolvconf*. I prefer non-systemd resolvconf. I tried installing it to see if it would fix my VPN DNS. The error message "status: resolve call failed: Unit dbus-org.freedesktop.resolve1.service not found." went away. But it still didn't work. Once I uninstalled systemd-resolvconf, reinstalled resolvconf and downgraded to 240.95 from 241.7 my vpn started working again.
Comment by loqs (loqs) - Monday, 25 February 2019, 20:37 GMT
You prefer non-systemd resolvconf but vpnc will use systemd-resolved via busctl if it detects resolv in nsswitch.conf it does not check if systemd-resolved is active or providing /etc/resolv.conf
resolvconf either version will not be used in this case.
Comment by Matthew Hiles (zashi) - Monday, 25 February 2019, 20:49 GMT
I don't know enough about the internals so this might be a pointless clarification, but I'm using openconnect, not vpnc.
Comment by loqs (loqs) - Monday, 25 February 2019, 21:01 GMT
Easy way to test my theory it is using it internally
change line /etc/vpnc/vpnc-script line 121 from
RESOLVEDENABLED=1
to
RESOLVEDENABLED=0
it will rely on either a working resolvconf (i.e. openresolv + glibc resolver or systemd-resolved + systemd-resolvconf) or /etc/resolv.conf being the actual file used used by the glibc resolver.
before it relied on systemd-resolved, did not work with the glibc resolver and would not use resolvconf
Comment by a10b (a10b) - Friday, 08 March 2019, 17:49 GMT
@loqs, gitlab user trygveaa proposed a patch for this in the openconnect mailing list: http://lists.infradead.org/pipermail/openconnect-devel/2018-August/005009.html, as referenced by this bug: https://gitlab.com/openconnect/openconnect/issues/22.

---
vpnc-script | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/vpnc-script b/vpnc-script
index 6a55546..b00dbb9 100755
--- a/vpnc-script
+++ b/vpnc-script
@@ -116,8 +116,7 @@ else
ifconfig_syntax_ptpv6=""
fi

-grep ^hosts /etc/nsswitch.conf|grep resolve >/dev/null 2>&1
-if [ $? = 0 ];then
+if grep -qs '^hosts.*resolve' /etc/nsswitch.conf && (command -v systemd-resolve && systemd-resolve --status) >/dev/null 2>&1; then
RESOLVEDENABLED=1
else
RESOLVEDENABLED=0
--

That did solve the issue for me when applied locally. I also use openconnect, but do not want to use systemd-resolved.
Comment by John Henderson (jwhendy) - Saturday, 09 March 2019, 15:13 GMT
@loqs: sorry for the late reply; I use openresolv.

The patch posted by a10b works, though I still get the error 'Error: any valid prefix is expected rather than "dev".' This is with systemd-resolved disabled/stopped, so that's nice. This is equivalent behavior to when I had systemd-resolved enabled (still go the 'dev' error).
Comment by a10b (a10b) - Monday, 11 March 2019, 21:05 GMT
Comment by Raphael Neumann (darophi) - Thursday, 14 March 2019, 08:47 GMT
The proposed patch(a10b) worked! Had to apply it to the vpnc-script located in /etc/vpnc/vpnc-script
Comment by Bachsau (Bachsau) - Monday, 25 March 2019, 02:36 GMT
That solves nothing. People can't be forced to use systemd-resolved. It is a bug that needs to be fixed.
Comment by loqs (loqs) - Monday, 25 March 2019, 16:48 GMT
@Bashsau what do you believe the patch does? If you have tested the patch and it did not work what value was RESOLVEDENABLED set to in the script?
Who is suggesting you must use systemd-resolve? Who is suggesting it is not a bug that needs to be fixed?
Comment by Bachsau (Bachsau) - Monday, 25 March 2019, 17:32 GMT
I'm sorry. For some reason when I posted my comment, there were only the first four comments of this thread displayed, so my answer was directed to the comment by @bakgwailo.

Unfortunately my problem ist not with vpnc but NetworkManager, but otherwise the same. Even though it is configured to update resolv.conf directly (main.dns=default), it keeps spamming my log files with requests like this.

Mar 25 18:28:04 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:28:04 BachsauDesk dbus-daemon[614]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.
Comment by f (bakgwailo) - Wednesday, 31 July 2019, 16:55 GMT
@Bachsau

I never implied that, calm down.
Comment by Bachsau (Bachsau) - Wednesday, 31 July 2019, 17:38 GMT
It was no offence, just a note that your solution is not a general solution. And BTW, this thread is four months old. In the meantime I solved my problem by adding `systemd-resolved=false` to the main section of "/etc/NetworkManager/NetworkManager.conf" and removing `resolve [!UNAVAIL=return]` from "/etc/nsswitch.conf".
Comment by f (bakgwailo) - Wednesday, 31 July 2019, 18:57 GMT
Yeah, just meant my workaround I wasn't suggesting as the fix for everyone, just that it worked for me. Funny enough, I ended up switching from systemd-resolve all together to dnsmasq due to vpn issues, and, came back across this issue trying to get openconnect to work. I was apparently missing the edit to /etc/nsswitch.conf which now makes everything work great for me, so thank you ! Solved me a headache I have had for a bit now.
Comment by Levente Polyak (anthraxx) - Tuesday, 10 December 2019, 17:11 GMT
should be fixed since 1:0.5.3.r462.r78-1 is there still any problem? If so please work with upstream to resolve it. named version includes the backported DNS fixes

Loading...