What is The Purpose of Setting The Sysctl `debug.debugger_on_panic=1`?

Started by amuckart, February 27, 2026, 03:25:06 AM

Previous topic - Next topic
After a recent upgrade to Business Edition 25.10.2 resulted in a kernel panic that required on-site assisance to recover because it hung the firewall I went looking at the 'panic' related sysctls and noticed the sysctl debug.debugger_on_panic is set to 1.

Having this set means the firewall requires on site intervention to recover from a kernel panic which is suboptimal for a remote office firewall.

What's the purpose of this setting in OPNsense?

Thanks.

Not sure I get the relevance of the question but you're looking for

https://man.freebsd.org/cgi/man.cgi?query=ddb&apropos=0&sektion=4&manpath=FreeBSD+15.0-RELEASE+and+Ports&format=html

We don't ever set this value in our code so it is intended to do what FreeBSD intends.


Cheers,
Franco

Thanks Franco.

The issue that's bitten me a couple of times now doing upgrades of Business Edition at a remote office is something triggers a kernel panic on reboot, the firewall drops to KDB and just sits there until someone can physically access the console and restart it.

For a production firewall I would far rather have it auto reboot after 15 seconds

The Kernel Debugging chapter of the handbook says:
QuoteThe third way is that any panic condition will branch to DDB if the kernel is configured to use it. For this reason, it is not wise to configure a kernel with DDB for a machine running unattended.
To obtain the unattended functionality, add:

options    KDB_UNATTENDED

to the kernel configuration file and rebuild/reinstall.

In the Glossary it says:
Quoteoptions KDB_UNATTENDED: change the default value of the debug.debugger_on_panic sysctl to 0, which controls whether the debugger is entered on panic. When options KDB is not compiled into the kernel, the behavior is to automatically reboot on panic; when it is compiled into the kernel, the default behavior is to drop into the debugger unless options KDB_UNATTENDED is compiled in. If you want to leave the kernel debugger compiled into the kernel but want the system to come back up unless you're on-hand to use the debugger for diagnostics, use this option.

I see DDB and KDB options in the kernel, but not KDB_UNATTENDED.

I'll submit a feature request to add this.

Cheers.

Why don't you set it to 0, then? You can add arbitrary tunables from the UI.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

The argument it should be set to 0 in production releases is sound though.  I wonder if you could file a FreeBSD PR to suggest that change, probably by adding KDB_UNATTENDED when branching a release, bit like we do with MALLOC_PRODUCTION?

Quote from: Patrick M. Hausen on Today at 08:42:52 AMWhy don't you set it to 0, then? You can add arbitrary tunables from the UI.

According to the source code it's CTLFLAG_RWTUN which means tunable in GUI will put it in  loader.conf and it's active on bootup. But I still think this will prevent crash reports from panics and there is no best of both worlds.

Quote from: trasz@ on Today at 11:40:47 AMThe argument it should be set to 0 in production releases is sound though.  I wonder if you could file a FreeBSD PR to suggest that change, probably by adding KDB_UNATTENDED when branching a release, bit like we do with MALLOC_PRODUCTION?

I think that's fair and changed locally easy enough. The only repercussion are perpetual boot loops and the question what type of crashes happen during early boot before init takes over as we cannot record them using a ddb.conf setup and the fact that disabling debugger will also defang the ability to store the crash report (textdump, not a full kernel dump).


Cheers,
Franco