Arch Linux

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.

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!

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?

@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

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).

Uninstalling systemd-resolve and downgrading systemd to 240... from 241... resolved my issue.

@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.

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.

@jwhendy what do you want to control /etc/resolv.conf on your system if anything?

@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?

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.

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.

I don't know enough about the internals so this might be a pointless clarification, but I'm using openconnect, not vpnc.

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

@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.

@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).

The proposed patch(a10b) worked! Had to apply it to the vpnc-script located in /etc/vpnc/vpnc-script

That solves nothing. People can't be forced to use systemd-resolved. It is a bug that needs to be fixed.

@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?

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.

@Bachsau

I never implied that, calm down.

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".

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.

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