After CU202 trouble with unbound

Installing & Running IPFire Update Trouble
1

Several hours after the upgrade, DNS queries from hosts on my LAN started failing after running for months without a problem. Thinking that maybe a fix was available through a Pakfire update, I tried that. What I got was a whole string of errors. Here is a sample:

...
Jun 18 12:36:25 alex pakfire: DOWNLOAD INFO: Host: pakfire.ipfire.org (HTTPS) - File: 2.29-aarch64/lists/server-list.db
Jun 18 12:36:25 alex pakfire: DOWNLOAD INFO: 2.29-aarch64/lists/server-list.db has size of  bytes
Jun 18 12:36:26 alex pakfire: DOWNLOAD INFO: HTTP-Status-Code: 500 - 500 Can't connect to pakfire.ipfire.org:443 (Name or service not known)
Jun 18 12:36:26 alex pakfire: DOWNLOAD ERROR: 500 Can't connect to pakfire.ipfire.org:443 (Name or service not known)
...

Safari can download a server list pakfire.ipfire.org/2.29-aarch64/lists/server-list.db without a problem, why can’t Pakfire?

FWIW Network>Domain Name System >DNS Servers shows “Broken” even though the servers work fine if accessed directly (i.e. not through unbound).

What would be a good way to fix this?

pygr

2

A (first) remedy may be to do a
unboundctrl restart from a shell
while watching
/var/log/messages | grep unbound from another shell.

3

Bernhard, thank you for the quick reply. (re)starting unbound does seem to fix things – until the next reboot. Following your suggestion, I executed “unboundctrl restart”. The command seemed to succeed, but indicated that unbound wasn’t running in the first place. After the (re)start Pakfire succeeded in updating the server list and no obvious relevant errors appeared in /var/log/messages.

After a reboot “/etc/rc.d/init.d/unbound status” said “/usr/sbin/unbound is not running but /var/run/unbound.pid exists.” “dmesg | grep unbound” showed unbound was killed due to an Out of Memory Condition. Without unbound running, about 10% out of 1.8Gi is being used. When it is running, around 70% is used. Apparently, at some point during or after boot 1.8Gi is not enough.

Looking back at the memory status graph, I can see a drastic jump up in memory usage going from CU201 to CU202. Early reports indicate memory usage will go back down for CU203

4

I think you found the reason for your problem.
Unbound has tremendous problems in memory handling. See other threads about this.
This problem will not be solved by the devs of Unbound in short time, IMO.
This is the reason IPFire will change to Knotresolver with CU203.
For the time being, I can only recommend not to use big DBL lists in systems with little RAM space.
And it may be necessary not to change too much in the DNS configuration. The problem is the fastreload function ( minimal offtime of DNS responses, but leaving a copy of the config in memory ).

As you found, knotresolver in CU203 resolves not only DNS requests but the memory problem also :wink: .
Therefore it is urgent that many people test this CU. This can help to reach a release time soon.