Constant Pi-Star Failures/Reboots/Lost Connections

[N5JFP]

OK, so my issues with my repeaters has gotten deeper.

I noticed last night that both of them are receiving SIGTERM at the same time, every day. I have completely redone both repeaters software with fresh SD cards and a fresh Image (the latest Beta), I have put both STM32 DVM's on new Raspberry Pi 3B+'s, I have also disabled all but 2 or 3 modes, and I still am having the issues. I checked voltages on both (both were good and the Pi reported no voltage issues); My network is locked down and only necessary ports are open (especially for my C-Bridge Links); I've also checked on overheating issues and neither shows temperatures ever above 103 degrees.

What could possibly be causing this? I had ZERO issues until the last updates came out, and now it doesn't work properly. It may stay on and working for several hours, and then when I check on both they've reset themselves and nothing is working properly (especially D-Star).

I also have analog controllers interfaced to both machines and they've been rock solid with ZERO issues.

Help! I don't know if I need to try a different image (someone said the Orange Pi image works on the 3B+).

I have looked at all of the logs and I cannot see any reason for these things to be doing what they are. I have noticed an occasional buffer overflow on one of several different modes, but that usually resolves itself. This things resetting/rebooting constantly is also playing heck with my links to C-Bridge on both controllers, which is upsetting not only myself but the C-Bridge admins.

Any suggestion would be great. I troubleshot all logs and everything the Pi-Star group on Facebook recommended and nothing has changed.

The attached images are what I see upon logging into the admin control panel

[AF6VN]

Question: WHAT TIME of day?

Have you examined the various crontab tables to see if some process is kicked off near that time of day?

Mine are:

Code: Select all

pi-star@pi-star-3b(rw):~$ cat /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=""

# m h dom mon dow user  command
*/5 *   * * *   root    /usr/local/sbin/pistar-upnp.service start > /dev/null 2>&1 &
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 3    * * *   root    mount -o remount,rw / && cd / && run-parts --report /etc/cron.daily
47 3    * * 7   root    mount -o remount,rw / && cd / && run-parts --report /etc/cron.weekly
52 3    1 * *   root    mount -o remount,rw / && cd / && run-parts --report /etc/cron.monthly
pi-star@pi-star-3b(rw):~$ ls /etc/cron.hourly/
fake-hwclock  pistar-hourly
pi-star@pi-star-3b(rw):~$ ls /etc/cron.daily/
apt-compat  bsdmainutils  exim4-base  man-db  passwd        powersave
aptitude    dpkg          logrotate   ntp     pistar-daily  samba
pi-star@pi-star-3b(rw):~$ ls /etc/cron.weekly
man-db
pi-star@pi-star-3b(rw):~$ ls /etc/cron.monthly
pi-star@pi-star-3b(rw):~$

pistar-daily runs a script that does a LOT of stuff, shutting down services, updating the PiStar databases, restarting services... Unfortunately, it defaults to sending all output from those actions to the bit-bucket so if one of them is failing it may not be apparent.



Observation, probably not significant: US Brandmeister masters do not support use of reflectors, so having a timeout to reset a reflector seems futile
https://wiki.brandmeister.network/index ... of_America

Reflectors are disabled on all the USA Masters. The associated talk groups for reflectors should be used instead of reflectors. These also means the DV4Mini and extended routing will no longer function. Other masters outside of the USA may accept these connections.