Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#1019140: unbound-resolvconf.service will always be in failed state when you set RESOLVCONF=false

1,534 views
Skip to first unread message

Thomas Deutschmann

unread,
Sep 4, 2022, 9:30:03 AM9/4/22
to
Package: unbound
Version: 1.16.2-1
Severity: normal

Dear Maintainer,

I am using unbound as recursive dns resolver for my local network,
not just for localhost.

My /etc/resolv.conf is mintainted by systemd-resolved and DNS server gets
set by systemd-networkd.

In the past, unbound-resolvconf.service was skipped:

Aug 25 03:51:47 router systemd[1]: Unbound asyncronous resolvconf
update helper was skipped because of a failed condition check
(ConditionFileIsExecutable=/sbin/resolvconf).

Since systemd was upgraded (251.3-1 -> 251.4-3) and systemd-resolved
became an own package which now provides /sbin/resolvconf, unit is no
longer being skipped and fails now:

Sep 04 14:46:59 router resolvconf[1078]: No DNS servers specified,
refusing operation.

Because DNS server is getting set via systemd-networkd/systemd-resolved
on this box, I created

$ echo RESOLVCONF=false > /etc/default/unbound

However, while resolvconf part is now beeing skipped by
/usr/libexec/unbound-helper,
unit is still failing:

Sep 04 14:50:38 router systemd[1]: Started Unbound asyncronous
resolvconf update helper.
Sep 04 14:50:38 router systemd[1]: unbound-resolvconf.service: Main
process exited, code=exited, status=1/FAILURE
Sep 04 14:50:38 router systemd[1]: unbound-resolvconf.service: Failed
with result 'exit-code'.

This seems to happen because of

$ /usr/libexec/unbound-helper resolvconf_start
+ UNBOUND_CONF=/etc/unbound/unbound.conf
+ UNBOUND_BASE_DIR=/etc/unbound
+ unbound-checkconf -o chroot
+ CHROOT_DIR=
+ DNS_ROOT_KEY_FILE=/usr/share/dns/root.key
+ ROOT_TRUST_ANCHOR_FILE=/var/lib/unbound/root.key
+ RESOLVCONF=true
+ ROOT_TRUST_ANCHOR_UPDATE=true
+ [ -f /etc/default/unbound ]
+ . /etc/default/unbound
+ RESOLVCONF=false
+ RESOLVCONF=false
+ do_resolvconf_start
+ [ false != false -a -x /sbin/resolvconf ]
+ return
router ~ $ echo $?
1



-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages unbound depends on:
ii adduser 3.128
ii init-system-helpers 1.64
ii libc6 2.34-7
ii libevent-2.1-7 2.1.12-stable-5+b1
ii libnghttp2-14 1.49.0-1
ii libprotobuf-c1 1.4.1-1
ii libpython3.10 3.10.6-1
ii libssl3 3.0.5-2
ii libsystemd0 251.4-3
ii lsb-base 11.2

Versions of packages unbound recommends:
ii dns-root-data 2021011101

Versions of packages unbound suggests:
ii apparmor 3.0.7-1
ii openssl 3.0.5-2

-- no debconf information

Thomas Deutschmann

unread,
Oct 4, 2022, 11:50:04 AM10/4/22
to
Hi,

may I suggest to apply the following changes?

> $ diff -u /usr/libexec/unbound-helper.ori /usr/libexec/unbound-helper
> --- /usr/libexec/unbound-helper.ori 2022-10-04 17:25:48.531922943 +0200
> +++ /usr/libexec/unbound-helper 2022-10-04 17:26:58.143255583 +0200
> @@ -24,7 +24,7 @@
> fi
>
> do_resolvconf_start() {
> - [ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return
> + [ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return 0
>
> unbound-checkconf $CHROOT_DIR/$UNBOUND_CONF -o interface | {
> default=yes
> @@ -44,13 +44,13 @@
> }
>
> do_resolvconf_stop() {
> - [ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return
> + [ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return 0
>
> /sbin/resolvconf -d lo.unbound
> }
>
> do_chroot_setup() {
> - [ -n "$CHROOT_DIR" -a -d "$CHROOT_DIR" ] || return
> + [ -n "$CHROOT_DIR" -a -d "$CHROOT_DIR" ] || return 0
> if [ "$CHROOT_DIR" != "$UNBOUND_BASE_DIR" ]; then
> # we probably should not do the force-recreate but just a refresh
> rm -rf "$CHROOT_DIR/$UNBOUND_BASE_DIR"
> @@ -79,7 +79,7 @@
> do_root_trust_anchor_update() {
> [ false != "$ROOT_TRUST_ANCHOR_UPDATE" -a \
> -n "$ROOT_TRUST_ANCHOR_FILE" -a \
> - -r "$DNS_ROOT_KEY_FILE" ] || return
> + -r "$DNS_ROOT_KEY_FILE" ] || return 0
>
> if [ ! -e "$ROOT_TRUST_ANCHOR_FILE" ] ||
> # we do not want to copy if unbound's file is more recent

Without a return value, return would return the result of the previous
if clause which is set to FALSE when the feature or condition isn't met.

Thanks!


--
Regards,
Thomas

Michael Tokarev

unread,
Jan 12, 2023, 10:50:04 AM1/12/23
to
Control: tag -1 + moreinfo

On Tue, 4 Oct 2022 17:31:42 +0200 Thomas Deutschmann <whi...@whissi.de> wrote:
> Hi,
>
> may I suggest to apply the following changes?

> > do_resolvconf_start() {
> > - [ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return
> > + [ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return 0

I think it's too late already. Most of these scrips has been rewritten in the later
version. See https://salsa.debian.org/dns-team/unbound/-/blob/master/debian/unbound-helper

Can you check if 1.17 works for you? If you want to, I can provide a bullseye build of
unbound (since this is what I use myself) - apparently I thought about uploading it to
bpo11 but forgot, for whatever reason.

Thanks,

/mjt

Michael Tokarev

unread,
Jan 12, 2023, 10:50:04 AM1/12/23
to
12.01.2023 18:40, Michael Tokarev wrote:
> Control: tag -1 + moreinfo
>
> On Tue, 4 Oct 2022 17:31:42 +0200 Thomas Deutschmann <whi...@whissi.de> wrote:
>> Hi,
>>
>> may I suggest to apply the following changes?
>
>> >  do_resolvconf_start() {
>> > -    [ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return
>> > +    [ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return 0
>
> I think it's too late already. Most of these scrips has been rewritten in the later
> version.  See https://salsa.debian.org/dns-team/unbound/-/blob/master/debian/unbound-helper

Hmm. But it looks like the same construct is used in the new version too.. :))

/mjt

Thomas Deutschmann

unread,
Apr 9, 2023, 6:10:04 PM4/9/23
to
Hi,

any reason why you didn't apply same fix to
|do_root_trust_anchor_updatefunction or did you just miss that function?|

|
|

|Regards,
Thomas
|
0 new messages