pfSense Guru's -
[using urrent (stable) version of pfSense]
I recently configured pfBlocker and it's been working for a few days. Last night I see this:
16:50:30 PHP ERROR: Type: 1, File: /usr/local/pkg/pfblockerng/pfblockerng.inc, Line: 2521, Message: Allowed memory size of 536870912 bytes exhausted (tried to allocate 268435464 bytes)
and unbound is down. I start it back up and it seems to work fine.
Then I add a hostname/ip to my local subnet and unbind fails to restart.
It appears to be overwriting my root.key used for DNSSEC and doesn't update it. Similar to this bug:
So I logged in and started a shell and did a unbount-anchor and then a:
cd /var/unbound; cp /usr/local/etc/unbound/root.key .
Unchecked the box for DNSSEC in unbound = same results when trying to restart unbound every time:
The following input errors were detected:
The generated config file cannot be parsed by unbound. Please correct the following errors:
/var/unbound/test/unbound_server.pem: No such file or directory
 unbound-checkconf[67987:0] fatal error: server-cert-file: "/var/unbound/test/unbound_server.pem" does not exist
I then removed my pfBlocker package entirely... unbound still won't start.
So I copy all the *.key and *pem files to /var/unbound/test but the startup seems to over write them at every startup attempt.
So right now I am unable to start unbound... has anyone seen this before?
If so, what's the chicken-or-the-egg workaround?
Any help would be greatly appreciated.
also check your config.xml, it should not be larger than a few megabytes
i suggest you to reinstall, something is screwed up anyway
@tazmo I am having the same issue, I took all packages off and tried all settings in the resolver with no luck. The service seems to hang up and not restart every time the DHCP service is used at all.
First, thank you @kiokoman for the link.
When I tried to edit a file, I discovered that pfBlocker caused my /var to fill up.
Since unbound creates a /var/unbound/test and writes tmp files to it, it could not.
Interesting side effect, before it does, it appears that it zero's out the /var/unbound/root.key BEFORE recreating all the necessary files in /var/unbound/test first.
So if /var is full, it appears to break unbound.
One is not reproducible and the other is labeled not a bug.
Fill up /var as a test to reproduce.
I would think on memory constrained devices (like Arm based pfSense hardware) you would want to check free space before writing temp/test files but maybe that's not considered a bug.... but removing the root.key (the file ends up zero length) and not being able to restart unbound after freeing up space in /var seems like a bug to me... ?