clog_pfb drops a core if system log files are reset

using the latest pf_blockerng_devel

clog_pfb core faults if log files are reset using Status->System Logs->Settings->Reset Log Files

Not a show stopper in anyway, just have to restart the pfb_filter process and all is right.

I have no idea if this is 2.4.5 specific or not. Never reset the log files until 2.4.5 while trying to get a handle on the latency/packet loss issue.

BBcan177

@jwj said in clog_pfb drops a core if system log files are reset:

using the latest pf_blockerng_devel
clog_pfb core faults if log files are reset using Status->System Logs->Settings->Reset Log Files
Not a show stopper in anyway, just have to restart the pfb_filter process and all is right.
I have no idea if this is 2.4.5 specific or not. Never reset the log files until 2.4.5 while trying to get a handle on the latency/packet loss issue.

In newer versions of pfSense, clog has been changed to use the "tail" command. Tail has a "-F" argument that allows it to re-establish connection to a reset log file:

https://unix.stackexchange.com/questions/291932/what-is-the-difference-between-tail-f-and-tail-f/291935

Here is the pfb_filter service script snippet:

/usr/local/etc/rc.d/pfb_filter.sh

    ```
    if [ -e '/var/log/filter.log' ]; then
            # clog is not required for pfSense 2.5 and above
            if [ -e "/usr/local/sbin/clog_pfb" ]; then
                    /usr/local/sbin/clog_pfb -f /var/log/filter.log | /usr/local/bin/php_pfb -f /usr/local/pkg/pfblockerng/pfblockerng.inc filterlog &
            else
                    /usr/bin/tail_pfb -F /var/log/filter.log | /usr/local/bin/php_pfb -f /usr/local/pkg/pfblockerng/pfblockerng.inc filterlog &
            fi
    fi

I use tail -f all the time.

Reset the log files just a moment ago.

Screen Shot 2020-03-30 at 11.54.54.png

Screen Shot 2020-03-30 at 11.55.22.png

Screen Shot 2020-03-30 at 11.58.12.png

BBcan177

@jwj said in clog_pfb drops a core if system log files are reset:

I have no idea if this is 2.4.5 specific or not. Never reset the log files until 2.4.5 while trying to get a handle on the latency/packet loss issue.

I tried to reset on my test pfSense 2.4.5 VM in ESXi and had no issue resetting the logs... Maybe this is related to the other issues? Are you in a physical box or a Virtual machine? Details?

Bare metal. Supermicro 5018D-FN4T. 32gb ram. 2.4.5 upgraded from 2.4.4-p3. zfs file system. I use the igb interfaces not the ix interfaces.

Overkill for my home network is a huge understatement, this was repurposed from a kvm host a couple of years ago.

BBcan177

@jwj

Can you try this?
https://forum.netgate.com/topic/151690/increased-memory-and-cpu-spikes-causing-latency-outage-with-2-4-5/43

Up the table entries? I'm already at 4 million. Go higher?

BBcan177

@jwj
If you are seeing the pfctl maxing out, then yes try to increase that value.

Will do. I'll let you know. May take a moment, my kids are at home doing online school work ;)

OK.

Set the table entries to 9 million. Rebooted. No change.

Turned off block bogons on my WAN. Rebooted. The Latency issue continues, but to a lessor degree. That ipv6 bogon table is (was) enormous. (Edited to say bogonsv6 is only 110 thousand or so. Not all that big)

Still drops a core if I reset log files.

These are two unrelated issues.

If I look at top when doing a filter reload pfctl goes to 100% for just a second or two. The benefit of fast HW. I imagine low powered gear gets slammed.

Edited: Tried 20 million just for kicks. No change. There must be some regression in the packet filter with FreeBSD 11.3.

I think I'll do a fresh install of 2.4.5 when I can just to make sure. If that's not helpful it's back to 2.4.4-p3.

FWIW: did a fresh install. Still core faults if I reset logs.