ASL3 bug - non responsive- PTT get instant "node 48654 timeout"

********** AllStarLink [ASL] Version Info **********

OS : Debian GNU/Linux 12 (bookworm)
OS Kernel : 6.12.34+rpt-rpi-v8

Asterisk : 22.4.1+asl3-3.5.5-1.deb12
ASL [app_rpt] : 3.5.5

Installed ASL packages :

Package Version
============================== ==============================
allmon3 1.6.0-3.deb12
asl3 3.8-1.deb
asl3-asterisk 2:22.4.1+asl3-3.5.5-1.deb12
asl3-asterisk-config 2:22.4.1+asl3-3.5.5-1.deb12
asl3-asterisk-modules 2:22.4.1+asl3-3.5.5-1.deb12
asl3-menu 1.14-1.deb12
asl3-pi-appliance 1.10.0-1.deb12
asl3-tts 1.0.1-1.deb12
asl3-update-nodelist 1.5.1-1.deb12
cockpit 287.1-0+deb12u3
cockpit-bridge 287.1-0+deb12u3
cockpit-networkmanager 287.1-0+deb12u3
cockpit-packagekit 287.1-0+deb12u3
cockpit-pcp 287.1-0+deb12u3
cockpit-sosreport 287.1-0+deb12u3
cockpit-storaged 287.1-0+deb12u3
cockpit-system 287.1-0+deb12u3
cockpit-wifimanager 1.1.1-1.deb12
cockpit-ws 287.1-0+deb12u3
dahdi 1:3.1.0-2
dahdi-dkms 1:3.4.0-7.asl
dahdi-linux 1:3.4.0-7.asl

=========================

Pi4 in heatsink metal case w cool temps. USB URI interface to Motorola 1225 repeater in a box. No addtl software aside from a utility or 2 like Midnight Commander.

This has happened a few times now after about a 12hour period or so. Node has been left connected to 458800 each time (I think but not 100% sure). Goes non responsive other than when keyed into it over rf it is transmitting “node 48654 timeout” even before I unkey.

System ran fine since day ASL3 was released and I started from scratch. I run the updates often and I just power cycled it and see there are bug fixes today which I am installing now. Thanks.

Tonight system disconnected and became erratically responsive to DTMF. (was on 458800 for only a few hrs tonight before issues occurred) Got home and could not control via Allscan. Noticed memory usage was high. Restarted asterisk a couple of times. Eventually it became responsive but now just testing it and still has issues. For example no tones or spoken audio when sending DTMF commands- other times yes. So, system continues to be a bit erratic- is there any way to diagnose with sys diagnostic reports or something? I will try connecting long stretches but to a different node

What specifically had high memory? Use top -d1 and press M (captial M) to sort by memory size.

Are there any errors in /var/log/asterisk/messages? What about the output of dmesg (before a reboot)?

UPDATE 9/26/25- RAM use goes up steadily even when idle and no connections to other nodes.

UPDATE 9/22/25- after about 14hrs or so the RAM use by cockpit had left less than 200MB free- swap was fine. Logging out of cockpit and back in freed up RAM and after clicking all cockpit pages was using 10% RAM.

UPDATE 9/21/25 10pm node running continuous connected to 458800- then about an hour later- System became totally non-responsive and power/HDD lights were both solid. Had been connected to 458800 and just idle on my end. Used it about an hour or so prior was fine. Had to power cycle and RAM avail 1.38GB and swap avail 2.15GB avail after restart.

Thx- is this data to be gathered when issues are present? Currently:

Cockpit-bridge at 74% of the 2GB this Pi4

cockpit-pcp at 11% (all the remaining processes are using tiny amounts) 45MB available

swap has less than 300KB avail on a 32GB card that has 21GB free and 465MB free on boot/firmware

no errors in logs just some warnings

dmesg has a -lot- of stuff-

Wonder if it is a memory leak that has creeped into the code- there was similar leak a long while back that the developers solved. I appreciate those with the code skills working on ASL3. I have become a regular donor to ASL and encourage others to do same.

Related?

Added updates above. Today RAM and swap full and ASL non-responsive via cockpit interface. No SSH, and green and red lights on Pi4 solid. Green being solid is storage activity so not sure if it is working hard because swap and ram are totally full or means something else. I was about to reboot it but will let it sit and see if SSH eventually connects and allows any interactions.

@Mason10198 provided a link to a related discussion that referenced a known memory issue with Cockpit.

Specifically : [cockpit/python]-bridge memory usage/leak (systemd pkg?)

I believe the workaround is to NOT keep a Cockpit window open all the time. Visit the page when needed and then close the window.

Thx. Oddly my node went months without this issue then it resurfaced. I hope the devs are able to get to the bottom of the bug. 73

Just so you know, this is an issue that needs to be addressed by the "Cockpit" developers, not the ASL3 dev team.