New messages after update to 2.4.1



  • 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


  • Moderator

    @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



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

    T.



  • 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]....
    


  • 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?



  • @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.



  • @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



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



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



  • '< 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?



  • @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>



  • 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.?.



  • @PiBa:

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

    "strstr" to "DIOCXCOMMIT" will do ^^



  • @Gertjan

    Fantastic! Changing DIOCADDALTQ to DIOCXCOMMIT works!

    Cheers
    Thomas


Log in to reply