RPi 4 Model B Rev 1.1
6.12.20+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.20-1+rpt1~bpo12+1 (2025-03-19) aarch64 GNU/Linux
pmlogger.service enabled, RPI dmesg/kernel throws these continuously:
[ 63.203726] mempolicy: Request to set policy to 5 ignored
[ 63.203740] mempolicy: Request to set policy to 3 ignored
[ 65.680779] mempolicy: Request to set policy to 5 ignored
[ 65.680794] mempolicy: Request to set policy to 3 ignored
[ 71.536820] mempolicy: Request to set policy to 5 ignored
[ 71.536835] mempolicy: Request to set policy to 3 ignored
[ 71.544330] mempolicy: Request to set policy to 5 ignored
[ 71.544344] mempolicy: Request to set policy to 3 ignored
[ 73.389680] mempolicy: Request to set policy to 5 ignored
[ 73.389695] mempolicy: Request to set policy to 3 ignored
[ 94.411924] mempolicy: Request to set policy to 5 ignored
[ 94.411939] mempolicy: Request to set policy to 3 ignored
[ 126.920520] mempolicy: Request to set policy to 5 ignored
[ 126.920539] mempolicy: Request to set policy to 3 ignored
[ 214.615107] mempolicy: Request to set policy to 5 ignored
[ 214.615122] mempolicy: Request to set policy to 3 ignored
Turn off pmlogger in Metrics settings in web interface, they stop.
Appears pmlogger might be built incorrectly for Rpi.
(Above log warnings are at "info" logging level, or visible in raw dmesg.)
No particular effect other than unnecessary logging load / hard on flash storage...
Would prefer to run with Metrics on... but not if it's doing that...
By the way, packages list of packages that upgraded tonight 4/1/2025 when I checked it for updates...in case helpful...
And yes, I'm running systemd-networkd and systemd-resolved instead of Network Manager on this particular Pi, unrelated ... but in case anyone noticed those updated also... way faster than NetworkManager for a fixed Ethernet IP config at startup. (Which is neither here, nor there, just explaining why...)
Also, can confirm the raspi-firmware and boot loader updates were successful without issue here, your mileage may vary... (I always have bootable backups on separate media these days on RPi, having been burnt by that before...)
asl3-asterisk
asl3-asterisk-config
asl3-asterisk-modules
asl3-menu
asl3-pi-appliance
base-files
curl
dahdi-dkms
dahdi-linux
dns-root-data
exim4-base
exim4-config
exim4-daemon-light
libapache2-mod-php8.2
libcurl3-gnutls
libcurl4
libfreetype6
libmariadb3
libnss-myhostname
libnss-resolve
libpam-systemd
libpq5
libsystemd-shared
libsystemd0
libudev1
libxslt1.1
linux-headers-6.1.0-32-arm64
linux-headers-6.1.0-32-common
linux-headers-6.12.20+rpt-common-rpi
linux-headers-6.12.20+rpt-rpi-2712
linux-headers-6.12.20+rpt-rpi-v8
linux-headers-arm64
linux-headers-rpi-2712
linux-headers-rpi-v8
linux-image-6.12.20+rpt-rpi-2712
linux-image-6.12.20+rpt-rpi-v8
linux-image-rpi-2712
linux-image-rpi-v8
linux-kbuild-6.12.20+rpt
linux-libc-dev
mariadb-common
php8.2
php8.2-cgi
php8.2-cli
php8.2-common
php8.2-curl
php8.2-opcache
php8.2-readline
php8.2-sqlite3
raspi-config
raspi-firmware
raspi-utils
raspi-utils-core
raspi-utils-dt
raspi-utils-eeprom
raspi-utils-otp
raspinfo
rpi-eeprom
systemd
systemd-resolved
systemd-sysv
systemd-timesyncd
tzdata
udev
vim-common
vim-nox
vim-runtime
vim-tiny
wget
Minor nitpick:
asl3-pi-appliance fails upgrades if avahi-daemon is disabled and masked in systemd.
Zero need for multicast DNS in the network this Pi lives in, got DNS handled... but I understand it's forced to make ".local" silliness work... Grin...
Avahi is basically required on the Pi appliance, because the Pi appliance is intended for... well... appliance operators - users who typically fall into the category of not knowing how to find an IP address, or what an IP address even is. A quick browse around this community board will quickly verify that the ASL userbase is saturated with such individuals.
The Pi appliance is the idiot-proof version of ASL. Cockpit is for those that fear a CLI. If you're a power user and want to take control, just manually install the ASL3 packages on top of a barebones Debian installation.
FWIW this is not specifically an asl3 issue, more to do with latest kernel on Pi4. Since the kernel upgrade I'm seeing this on a Pi4 which isn't running asl but not on the Pi3 which is running asl3.
The Pi Appliance is designed specifically around a certain set of functionality and does not support deviations from its ideal. The asl3-pi-applaince package is, in common online parlance, "opinionated" about what it does. It should also be clear that that package has all sorts of various actions it will take for force conformance into a specific set of configurations and conditions. It is not tested for general compatibility but rather for conformance (and a forceful return to conformance if necessary) of the concept of the "ASL3 Pi Appliance".
Bottom line - If you want a stable, long-term customized OS for your specific needs, I would strongly suggest NOT using that package/image.
In the case of the rolling memory errors, I suspect some piece of code in the overall package is ignoring something in the build for Pi4 that's been hard-set for memory allocation for whatever reason the Pi folks set it... (often... none... Pi builds are truly maddening... haha...)...
Searches tend to indicate numerous folks (including Geerling) have been messing with Pi4 memory allocation kernel settings for a couple of YEARS to "set world records"... but little on anyone chasing STABILITY in those settings! (GRIN!)
Oh well... seems like nearly anything that allocates significant memory / perhaps hits swap (still investigating) triggers that continuous set of errors on the current Pi4 build. The logger causing it was a red herring -- it simply hits RAM use harder than anything else...
Shutting down the logger certainly helps by a LOT... will see if I have time to figure out what is set wrong in the most current Pi4 kernel memory config... nothing immediately jumped out at me in those threads from the folk messing about with "setting records"... haha...
Thanks for confirmation it's happening generically on Pi4.
Yeah, I'll have to look into that. The postinst script is definitely calling it using the dh_ call which should be "protecting" systemctl errors from errors. However postinst is manipulating the Avahi configuration and is not manipulating NetworkManager. NetworkManager is needed for Cockpit but not asl3-pi-appliance.
Technically Cockpit doesn't seem to care much, it just offers to reinstall NetworkManager -- which I bet could make a mess if it tried to do it itself -- I assume Cockpit isn't systemd network aware... (GRIN!)... I was surprised it "offers" to fix it... yikes...
I was going to leave NetworkManager on the Pi, but I ran into a verrrrry interesting race condition -- if you boot an RPi from VERY slow storage (long story)... the various network checks including DVSwitch's get fooled that network is up long before it really is.
Even the file updaters start trying -- and they're not supposed to.
Basically storage has to be SO slow that systemd thinks it launched networking, but then networking still takes a while and systemd has "moved on" and starts launching other things dependent on network... before it's ACTUALLY ready...
Not really an ASL3 problem - a systemd problem.
Switching to systemd networking cut the time to bring the interface up in HALF... which was a surprise to me... I've used it on static IP servers before, of course... but nobody ever times the Ethernet start-up times these days...
Felt like a blast from the past by two decades, trying to find ways to start the network interface faster... LOL!
And eventually I fixed the storage issue... but it was a surprise how poor the systemd network dependencies behave. Or maybe it wasn't? Ha... yay systemd...
Ohhh well, this Pi certainly isn't going to be the end-result "Production" setup/hardware... it's just fun tinkering with it to get a nice clean package setup I'll be "Ansiblizing" (new word? ha!) on to better hardware...
No REAL complaints, just observations! Tinkering is fun.
I have a love-hate relationship with systemd. I think some of it is a massive improvement over SysV-Init such as ordered dependency solving, the nice way to handle complex scheduling tasks in timers, and the sane handling of the non-forking and one-shot startup models. However some stuff like systemd networking and resolver I am not a fan of at all. The only reason the Pi Appliance is using NetworkManager is for the niceties of Cockpit. I much prefer the old-school /etc/network structure.
