[arm-allstar] stops working

[Ken]

As I said, the failure mode is unpredictable. But, if you manage to get in
while the RPI is in that failed state and find no memory overflow, then you
have found a new bug and I would encourage the developers to figure out how
to fix it.   In mature software, more than half the code exits to deal with
error conditions, rather than the application function of the program..

 

73

Ken

 

From: Lawrence Roney [mailto:roney at chiarappa.com] 
Sent: Wednesday, October 30, 2019 11:57 PM
To: Ken <ke2n at cs.com>; arm-allstar at hamvoip.org
Subject: RE: stops working

 

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 <mailto:ke2n at cs.com> > 
Sent: Wednesday, October 30, 2019 8:42 PM
To: arm-allstar at hamvoip.org <mailto:arm-allstar at hamvoip.org> 
Cc: roney at chiarappa.com <mailto: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.