unbound stops and won't start again + high cpu

Pizzamaka

I installed 24.11 on an SG1100 and I have an issue where more or less 2-3 times a day unbound stops. The strange thing is, that it won't start through the UI anymore. If I run top on the shell i see that unbound + unbound-checkconf consume 100% CPU for some 2-5 minutes and then stop.

The strange thing is, that when I run Reload with pfblockerNG-dev it starts again.

The only packages I have are pfblockerNG-dev.

I see these logs when unbound stops:

bmeeks

The SG-1100 only has 1 GB of RAM. That is not really enough for a package like pfBlockerNG, especially when you use the DNSBL feature or the Python option for unbound (the DNS Resolver). Both of those choices can use a lot of RAM.

The error you are seeing is a quirk of how FreeBSD does memory management. The details get kind of geeky, but let me try a short version --

When the operating system needs to allocate more RAM to a process, and there is no free RAM actually available, then the FreeBSD OOM (out-of-memory) Killer is activated. This is an emergency routine which searches for the process currently consuming the highest amount of memory and then attempts to kill that process to recover its memory so it can satisfy the open allocation request. This whole scenario is not a good place to be in the computer world.

The fix is to either add more RAM, which unfortunately is not possible in the SG-1100, or trim down the options/features you are using so they consume less RAM. That means curtailing how you use pfBlockerNG in your case.

Pizzamaka

@bmeeks thank you! I already suspected RAM, but was hoping for another answer (and am saving for a 2100 ;-))...

What still puzzles me is why starting unbound through UI does not work whereas running pfblocker update does start unbound.

bmeeks

@Pizzamaka said in unbound stops and won't start again + high cpu:

What still puzzles me is why starting unbound through UI does not work whereas running pfblocker update does start unbound.

Not 100% sure, but it could be that when killed unbound leaves behind its PID file in /var/run/. A shell script could potentially just unilaterally delete any existing unbound PID file before attempting to restart it. That's just a guess on my part, though, as I have not looked at the code in the pfBlockerNG scripts.

When you attempt to restart the DNS Resolver from the GUI, do you see anything in the pfSense system log at that time mentioning a PID file for unbound? If you do, that would validate my guess.