Solved Firewall with FreeBSD 13.2 aarch64 on RPi4 (2GB): many processes failing with "failed to reclaim memory"

B

bplipschitz2

This machine is not working hard, it's only doing firewall/nat duties. (As an aside, I'm having the same problem with a RockPro64 board running FBSD 13.1). I'm a long time user of FBSD (since 3.9), but I've never run into this problem before.

Basically, I'm retiring my old Celeron 333MHz based firewall machine (384 MB of RAM, 4GB HDD, running FBSD 6.1 [don't laugh -- it's worked for ~ 20 years]), and am trying to do it with an SBC that eats a lot less energy and is quieter.

I'm guessing the issue has to do perhaps with the firewall (ipf) gobbling up all the RAM? Wasn't an issue with the old machine, and before enabling the firewall, neither of these machines had a problem (the RockPro64 ran fine for ~72 days because I forgot I fired it up for a burn in test). So, was gibt's? I suppose I can move to a different firewall filter implementation, but I'd rather not as I'm comfortable with ipf.

Is there a way to fix this? Prevent this? Anyone else have this problem? (Doesn't seem like it, digging around on teh innerwebs basically yielded zilch).

thanks

bpl
 
Maybe test FreeBSD 14.0-RELEASE version on your Raspberry Pi 4B or RockPro64 board? FreeBSD.org/where
https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/14.0/
https://ghostbsd-arm64.blogspot.com/2023/01/spruce-up-tools-to-view-amount-of-free.html Do you have other details like HTOP snapshot picture, PS AUX? freebsd-memory.sh output shared here. or freecolor appication
# pkg install freecolor
To see memory details, enter:
$ freecolor -m -o

https://www.skynats.com/blog/duf-disk-usage-free-utility-for-linux-bsd-macos-windows/
BSD
  • FreeBSD: pkg install duf
# pkg install duf
# duf --help

# duf --version
duf 0.8.1 (3c55411)

# duf
 
As is often the case, it was a cascade of things. First, the swap file I created was not being mounted (new experience for me, they always seem to mount). Next, being an OF, I had set 'resolvconf' to 'no' in resolvconf.conf, because I can hardcode my own resolv.conf -- it hasn't changed in years.

This is the wrong way to do that. ;) The resolver was spawning a new 'resolvconf' for every DNS request from my internal network. Enough that it eventually ate up all the RAM.

Fixed that, Alles Gut now.

For now. . . ;)
 
You must log in or register to reply here.
Back
Top