New messages after update to 2.4.1

[esquire1968]

Hi!

After reconnection with the internet I get always the same error messages:

pf_busy

PF was wedged/busy and has been reset.	@ 2017-10-27 05:10:58

Filter Reload

There were error(s) loading the rules: pfctl: DIOCXCOMMIT: Device busy - The line in question reads [0]: @ 2017-10-27 05:10:59

Unfortunately I found no solution in the web. Please could you explain me the messages or give me a solution.

Thanks!

Thomas

[BBcan177]

@esquire1968:

pf_busy

PF was wedged/busy and has been reset.	@ 2017-10-27 05:10:58

Filter Reload

There were error(s) loading the rules: pfctl: DIOCXCOMMIT: Device busy - The line in question reads [0]: @ 2017-10-27 05:10:59

PiBa has a PR to hopefully fix that issue…

See here:
    https://github.com/pfsense/pfsense/pull/3857

[esquire1968]

Thanks for your answer! Unfortunately it doesn't work. When pfBlockerNG is deactivated, I get no error message after reboot.

T.

[Gertjan]

Humm.

Not using pfBlockerNG  - using 2.4.1-RELEASE (amd64) on a :

Intel(R) Pentium(R) 4 CPU 3.20GHz
Current: 2800 MHz, Max: 3200 MHz
2 CPUs: 1 package(s) x 2 hardware threads 
(from 2005 .....)

Applied the patch https://github.com/pfsense/pfsense/pull/3857

My pfSense still sings on boot :

PF was wedged/busy and has been reset.....
There were error(s) loading the rules: pfctl: DIOCXCOMMIT: Device busy - The line in question reads [0]....

[PiBa]

Can you try increasing the 'while ($pfctl_try < 10) {' to maybe 100 ? That would give it 20 seconds to settle its current activity..

Do you use any other packages like maybe ntop? Or anything else 'special' configured like aliases with url lists?

[Gertjan]

@PiBa:

Can you try increasing the 'while ($pfctl_try < 10) {' to maybe 100 ? That would give it 20 seconds to settle its current activity..

Will try that tomorrow.
@PiBa:

Do you use any other packages like maybe ntop? Or anything else 'special' configured like aliases with url lists?

Noop.
Avahi - NUT - Cron (but nothing added to the cron list) - ACME.

edit : Wait : I installed "munin-node" years ago. Runs every 5 minutes some perl and shell scripts (but nothing that touches pf I guess).
I'll ditch it by doing a complete clean re-install (switch to ZFS while doing so). Will report back.

[esquire1968]

@PiBa:

Do you mean 'while ($pfctl_try < 10) {' set to 100 in the original filter.inc or in the modified one?

I've the following packages installed:

bandwidthd
Cron
freeradius3
nut
openvpn-client-export
pfBlockerNG
RRD_Summary	
Service_Watchdog
snort

Thomas

[PiBa]

@esquire1968, In the 'patched' one, the original doesnt have the 'try loop'.

[esquire1968]

No changes! The same errors after setting '> 100'.  :(

[PiBa]

'< 100' right? you shouldn't change the <> sign. or did you mean you tried bigger numbers as well? just checking.. if so then we should try and figure out what is keeping pf busy / wedging it.. not really sure what path to investigate yet though..

Can you 'trigger' the problem while pfSense is running? Can you run "lsof /dev/pf" while its in that process? what processes have the pf device open?

[Gertjan]

@PiBa :
The filter reload (mine - as the others here) return :
" ….  pfctl: DIOCXCOMMIT ..." as a part of the notification.

Your patch is trying 10 times IF it detected a return 'error' lines that contains

strstr($_grbg, "DIOCADDALTQ: Device busy")

because it returns "…DIOCXCOMMIT " -> also known as "something else"  ;)
So, the "try 10 times" is never executed, the flow will break out right away.

When I changed

if (strstr($_grbg, "DIOCADDALTQ: Device busy")) {

for

if (strstr($_grbg, "DIOCXCOMMIT : Device busy")) {

is were no more notifications for me.

@IpBa : Thanks !!

Edit : when I added <developerspew>to the config.xml - below <pfsense><system>- , I actually saw that a second try was needed to put the rules in place :

pf was busy but succeeded after 2 tries @ 2017-10-31 11:51:44

This means (to me) that some race conditions exists ones during boot - and that the problem isn't actually a real one</system></pfsense></developerspew>

[PiBa]

Thanks Gertjan,
In my reproduction i'm sure it said 'DIOCADDALTQ' when i managed to reproduce 'something similar' and i guess i didn't look close enough at the actual message provided, i have changed my pull-request to include 'DIOCXCOMMIT'. Should be working for both cases now.

p.s. its without the space character before the colon right.?.

[Gertjan]

@PiBa:

p.s. its without the space character before the colon right.?.

"strstr" to "DIOCXCOMMIT" will do ^^

[esquire1968]

@Gertjan

Fantastic! Changing DIOCADDALTQ to DIOCXCOMMIT works!

Cheers
Thomas