PF was wedged/busy and has been reset. & error loading rules pfctl: DIOCADDRULE:
-
Hello,
I received two e-mails with notifications about one of my pfSense systems & the web interface has the same two notices:
1\. PF was wedged/busy and has been reset. 2\. There were error(s) loading the rules: pfctl: DIOCADDRULE: Device busy - The line in question reads [0]:
Running pfSense version:
2.3.2-RELEASE-p1 (amd64)
built on Tue Sep 27 12:13:07 CDT 2016
FreeBSD 10.3-RELEASE-p9Uptime 33 Days 15 Hours 13 Minutes 07 Seconds
Hardware is a SG-2440, with an mSATA & mini-PCI serial card (for GPS connection)
I have made no changes in at least weeks.
Can anyone help me understand what happened? Where should I look to troubleshoot? With the load error, should I be worried that NO rules were loaded?
I'm considering rebooting the system, but am not at the site (connected via OpenVPN.) I'll be at the site this evening and will probably reboot then.
Thanks for any insight and help anyone can provide.
Thanks,
Frank -
The only time I got that error is when I was converting some HFSC queues to FAIRQ, and FAIRQ generated that error when I tried to use a queue priority of 1 (only accepted priority of 2 or higher).
Basically that message is output from pfctl refusing to load the rules, so whatever rules it tried to load failed to load, but if there was rules already loaded, the old rules will stay active.
-
Thanks for the info.
I've made no recent changes. I am using CODELQ shaping to minimize buffer bloat, but it has been configured for about a month.
-
I have the same problem today. Also didn't change anything for weeks. 2.3.2-p1, full install AMD64.
-
I'm getting these randomly, no clear pattern, plus with the log entry useless as it is, very much doubt someone's going to pinpoint the cause.
-
I'm getting these randomly, no clear pattern, plus with the log entry useless as it is, very much doubt someone's going to pinpoint the cause.
Same with us on an SG-2220. Sometimes followed by loss of PPPoE/WAN which I am not sure if related (unplugging the WAN cable and reinserting kicks it all back in again).
-
What might be the most concerning about this is whether or not there is a secure firewall rule set in place when this happens.