[arm-allstar] stops working
Lawrence Roney
roney at chiarappa.com
Wed Oct 30 23:57:20 EDT 2019
Good tip Ken on the logging level. I don't think it is /var/log space related, however I will 'df' the next time it happens. I say this because local repeater functions start responding again and the node reconnects to our hub as soon as the Internet becomes available. No reboot is required to clear the issue and the 'uptime' command confirms that no reboot occurred.
73,
Lawrence
From: Ken <ke2n at cs.com>
Sent: Wednesday, October 30, 2019 8:42 PM
To: arm-allstar at hamvoip.org
Cc: roney at chiarappa.com
Subject: stops working
My theory on this is that the message area (/var/log ) overflows with various diagnostic messages related to the initial problem and then some part of the memory important to program operation gets overwritten and the program stops working properly (in various ways).
When you power-cycle the RPI, that memory area gets cleared so you never actually get to see the problem. And it starts working again.
Memory allocation
Filesystem Size Used Avail Use% Mounted on
/dev/root 3.6G 1.5G 2.0G 43% /
devtmpfs 464M 0 464M 0% /dev
tmpfs 468M 0 468M 0% /dev/shm
tmpfs 468M 13M 456M 3% /run
tmpfs 468M 0 468M 0% /sys/fs/cgroup
tmpfs 468M 4.6M 464M 1% /tmp
tmpfs 50M 520K 50M 2% /var/log
/dev/mmcblk0p1 100M 20M 81M 20% /boot
I have put in the fix (documented some time ago) that trims the log file periodically, but I think under some circumstances you could get 50M in a short while (a day).
One thing that *may* help is to set verbose=0 and debug=0 in the CLI.
You could also attach a small thumb drive (of some GB in size) and reallocate the memory map to put the log files there. That would have the advantage that - if the system has to be power cycled to get it going again - you would at least preserve the log files for later analysis.
73
Ken
KE2N
Scanned by Symantec Email Security.cloud service.
More information about the ARM-allstar
mailing list