On Wed, 16 Jun 2021 18:57:26 +0200 Dennis Filder <d.fil...@web.de> wrote:
Package: unbound
Version: 1.13.1-1
Severity: normal
Tags: patch
I ran out of space on /var and unbound still tried to update the root
trust anchor file which ended up empty. Then later after reboot the
package-helper failed to detect and recover from that, and
unbound.service failed to start.
With the attached patch (which adds a rudimentary sanity check) and
freshly freed disk space unbound started normally. However, a better
solution might be to test more carefully for sufficient disk space
when making changes to the file or using 2 oversized files in rotation
and never truncating them.
I wonder if we should address the root problem here instead of the
symptoms.
Maybe we can always update this (very small) file as a part of the
daemon startup procedure.
And/or, when doing this (it is just being copied to the chroot from
/usr/share/dns/root.key), unbound can do it atomically - copying it
to a temporary file and renaming it to the right place when done.
Unlike install(1), this will never result in having an incomplete
file in place (provided the filesystem is doing the right thing).
Yet another option is to compare the two files and copy over if the
files are different.
Neither of that requires verification of the validity of the file.
But it will surely change behavior if people used to keep their own
file in /var/lib/unbound/root.key - can this *ever* happen at all?
But this is not a conffile to begin with, if one wants to have their
own root.key, they sure can set ROOT_TRUST_ANCHOR_UPDATE=no in
/etc/default/unbound.
What do you think?
Thank you for the patch!
/mjt
P.S.: I also noticed that unbound.service under [Service] defines no
StateDirectory=/var/lib/unbound to ensure that it is mounted on start.
The chroot setup procedure has its own load of issues.
