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 (https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/#kerneldebug-online-ddb) 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 (https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/#kerneldebug-options) 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.
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 March 26, 2026, 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 March 26, 2026, 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
Requires onsite visit? Do you mean to be able to do "reboot" from the console, or recycle the power?
If that's the type of remote location it is, then maybe some form of out-of-band console access should be there?
Or, set that option to 0, and still evaluate OOB access.
Quote from: BrandyWine on March 28, 2026, 12:38:00 AMRequires onsite visit? Do you mean to be able to do "reboot" from the console, or recycle the power?
If that's the type of remote location it is, then maybe some form of out-of-band console access should be there?
Or, set that option to 0, and still evaluate OOB access.
Yes, it requires someone to be on-site to do a reboot from the console.
It's fine to have this feature available in the event that someone is experiencing persistent problems and needs debug information but there's no way it should be the default on a production firewall. The FreeBSD hadnbook even says this outright.
Quote from: Patrick M. Hausen on March 26, 2026, 08:42:52 AMWhy don't you set it to 0, then? You can add arbitrary tunables from the UI.
I do now. I don't think I should have had to deal with firewalls going offline and requiring remote hands to diagnose the issue and reboot to figure out I needed to do that though.