Good Morning,
thanks for the new 26.7!
OPNSense is a truly great product; thank you very much for maintaining and
further developing it.
The upgrade to 26.7 went smoothly. After two days of use, I've now noticed
Unbound crashing for the second time, with the following error message:
(unbound), jid 0, uid 59, was killed: failed to reclaim memory
After that, I can manually restart Unbound, and the system continues to run normally.
Any ideas?
Thanks a lot!
Hello!
I'm having a similar problem. unbound suddenly stops and doesn't restart with the following log message:
<6>[86420] pid 4171 (unbound), jid 0, uid 59: exited on signal 11 (no core dump - denied by kern.coredump)
It has already happened a few times after the 26.7 upgrade. I also can start it manually after that has happened.
Is there at least some way, I can make it restart automatically again after exiting?
Best wishes,
-fab-
Not sure if this is related or a different issue, but for me Unbound is crashing after rebooting OPNsense. It seems to happen with about 50% of reboots. Unbound starts running for a minute or so and then crashes. It works after I manually restart the service. I'm on 26.7.2.
The problem still exists.
I have created a workarround with a little script, which
was running every 15min via cron. The scripts restarts
unbound if necessary and logs the restart in
/root/unbound_restart.log:
my_unbound.sh:
my_unbound=$(pluginctl -s unbound status)
if [ "$my_unbound" == "unbound is not running." ]
then
pluginctl -s unbound restart
echo $(pluginctl -s unbound status)
echo $(date) >> /root/unbound_restart.log
fi
This works for me.
I haven't experienced this. how many DNSBL do you have added?
I have Steven Black and OISD
EasyList
EasyPrivacy
Steven Black List
YoYo List
Unbound crashes only after reboot in 50%.
No more issues after restarting unbound.
so upon reboot. no traffic is passing. or after a few minutes after the reboot?
I've been running 26.7 for 3-4 days now with no issues, I figured id test for. you
I have a snapshot of business edition I went back to. ran for a bit. then restored back to a 26.7 snap shot. I am not getting that error message.
I am using dns over tls to nextdns. and the blocklists above with no tweaks to unbound. more or less out of box
a few minutes after reboot
I've also see Unbound suddenly stop working, I also wrote a cronned script that checks if it is active and restarts it if necessary
Under logs is this listed under warning or error?
Seems there may be multiple different (but similar-ish) issues being discussed here.
For the OP; I *think* that "was killed: failed to reclaim memory" indicates that the system ran out of memory and started killing processes to try to reclaim some. Maybe you have insufficient memory, or some issue (not necessarily unbound) that's consuming more than it should be .... ?
Unbound temporarily consumes a lot of RAM when rebuilding Blocklists, maybe even more in recent versions. How much RAM do you have?
The message "failed to reclaim memory" is sent by the operating system kernel if it runs out of memory and kills a process to avoid crashing the complete system.
I can see two reasons:
- The hardware or VM just has too little memory for what you're trying to do.
- You're loading a lot of large block lists which consume unexpectedly large amounts of memory.
So I suggest checking if the system has a reasonable amount of memory to work with, and if not, you either have to do less (less large blocklists, disable things that consume large amounts of memory) or increase the amount of available memory.
I have 4 GB of RAM in the system. The system is running at 30% capacity.
When unbound crashing it occurs after the DNS blocklist is updated,
which is done via cron once a day.
However, unbound does not crash every day after the cron job runs.
today is the first time I have ever had ERRORS within unbound. I am not having any issues resolving
ill probably roll back to business edition now
Quote from: MiRei on August 26, 2026, 10:53:11 AMI have 4 GB of RAM in the system. The system is running at 30% capacity.
When unbound crashing it occurs after the DNS blocklist is updated,
which is done via cron once a day.
However, unbound does not crash every day after the cron job runs.
4 GB is not enough for newer versions with larger blocklists. It doesn't consume much while running, but dynamically it can shoot up rather high, especially for Unbound using blocklists. Try disabling them and see if the crashing changes.
What I've done for both unbound and suricata is to create 2 small bash scripts to monitor their status. If they get killed, they are restarted automatically.
root@fwall:~ # cat dnscheck.sh
#!/usr/local/bin/bash
LOGFILE="/root/log/unbound_monitor.log"
TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S")
if ! pgrep -x "unbound" > /dev/null; then
echo "$TIMESTAMP: Unbound process not found, restarting..." >> $LOGFILE
/usr/local/sbin/configctl unbound restart
echo "$TIMESTAMP: Unbound restart command executed" >> $LOGFILE
fi
root@fwall:~ # cat /etc/cron.d/dnscheck
*/5 * * * * root /root/dnscheck.sh > /dev/null
A major issue with DNSBL on opnsense is the lack of memory usage optimization when the blocklists get updated.
First issue is the blocklist update process loads all the blocklists in RAM then format them for Unbound, instead of streaming them.
Second issue is at DNSBL swap time, Unbound effectively has 2x all the blocklists loaded for a brief moment before releasing the old blocklist.
Both situations can lead to the highest memory consumer being killed by FreeBSD (expected behavior).
If you like to use DNSBL I recommend delegating that to a servicd that is designed specifically with large lists in mind. Like AdGuard Home which can run directly on OPNsense and comes with a much nicer UI to manage excepted devices, manual allowlists, statistics etc.