Feeder Outage: PiAware 'anyname' is not sending ADS-B data to FlightAware

FlightAware ADS-B Flight Tracking
1

Could someone come up with some code that if the Pi has lost connection with the world, that

  1. it attempts a tidy shutdown and restart
  2. if it’s really hung (so bad it won’t shutdown) the bcm_2708 watchdog brutally restarts the Ri (this, I believe, is similar to powering off powering on the Pi and so bad for the SD card but since the Pi has died power off / on is about the only way to get it back anyway shrug)

The watchdog timer is 15s maximum, so a keep alive pinger might need to kick every 10s, wait no more than 1s then have 4s to reboot.

some documentation on the watchdog timer is here http://blog.ricardoarturocabral.com/2013/01/auto-reboot-hung-raspberry-pi-using-on.html.

It might be useful if something like this was built in to PiAware.

2

The piaware sdcard image already enables the hardware watchdog.

3

How can we configure Pi aware to reboot if it stops communicating or to get the watchdog to do a reset if its in a panic state or something and cannot do a soft restart.

On restart, it shouldn’t start to process for the soft restart / hard reset unless communication has been established (so the Pi doesnt go into a restart loop if the comms fault is external.)

4

I’ve got a little script that will reset the network if it loses connection to my router, maybe that is all you need? If the device itself locks up this script won’t be of any use though (that would be damaged hardware though i presume and be easier fixed by changing the pi)

#!/bin/bash
exec &>>/tmp/pingfail_log
sleep 30
if ! [[ -a /tmp/pingfailed ]] && ! ping 192.168.2.1 -c5 >/dev/null
then
        echo "Restarting dhcpcd; could not reach 192.168.2.1"
        systemctl restart dhcpcd
        date
        touch /tmp/pingfailed
        sleep 300
        rm /tmp/pingfailed
fi

To “install” the script do the following:

nano /home/pi/pingfail.sh

Now paste the above script and save and exit (ctrl-o and ctrl-x)

The script needs to be executed regularly for that we use cron:

sudo crontab -e

This should open an editor, post the following line at the bottom:

*   *   *   *   *     /bin/bash /home/pi/pingfail.sh

Save and exit.

Now every minute the script is started.
It will wait 30 seconds (to give the network connection some time to come up after boot).
It will check if it can reach the ip address (set this to your router ip address).

If it can’t reach the ip it will restart dhcpcd. This is what needs to be done on Debian stretch and should therefore also work in piaware 3.6.3 sd-card image.

If you really want to just make it a reboot -f instead but be aware the pi will reboot 30 seconds after startup if it can’t reach the specified ip.

Now if you only restart dhcpcd it will only do that every 300 seconds. For that it just uses a file to mark it did a restart and removes the file after 300 seconds.
The script is being launched every minute and the following launch will check for the existence of the file and if it exists not do anything.

I’m not quite sure what exactly your problem is do you have logs or can the describe the issue better?

(I made this script because my wifi router sometimes get’s temperamental and won’t allow devices to authenticate. The pi then sets a rather long timeout before trying again and that is annoying.)

5

I’ll try that, but the real wish is to get the pi going again if stops communicating with the flightaware servers.

Really, I’m not too interested in what has actually gone wrong, I know that usually i cant ssh to the pi to diagnose. A power cycle gets it going again.

It would be good to attempt a soft restart if possible, but if the problem prevents this, then the watchdog forces a hard restart.

6

If you can’t ssh in it’s reasonable to assume it has somehow lost network connectivity, right?
As piaware activates the hardware watchdog it’s reasonable to assume that piaware and the rest of the pi is still running just not connected to the net.

reboot -f is fast and should be soft enough, it syncs and unmounts the file systems cleanly but doesn’t wait for all the services to shutdown.

Restarting dhcpcd won’t help if somehow the network driver acts up for example.
So if you want just go with the reboot.

Now you could do a ping to the flightaware servers as well but that does not make sense as your internet connection might just be down. That part of the problem piaware resolves just fine by itself after your internet connection comes back up.

Therefore testing for local connectivity makes more sense.
The reboot takes maybe 30 seconds so checking with ping more often than every 60 seconds doesn’t make much sense.

If you want to reboot the script becomes much simpler:

#!/bin/bash
sleep 120
if ! ping 192.168.2.1 -c5 >/dev/null
then
        reboot -f
fi

I’ve increased the sleep so after boot you have 2 minutes to rename the script so it doesn’t get executed on the next bootup (In case you got the ip wrong or something). It will still do a reboot after two minutes if it can’t reacht the ip but on the next boot it won’t get executed :slight_smile:

Hope the instructions are clear enough?

7

I started having this problem several months ago. I’ve tried different pi’s, different cards, and still the same problem. I have many pi’s dotted around my house and it is on the feeder that has issues. If I reset the connection on my router I am back up and running. So something is borked, on the connection, and it’s not terminal on the feeder as it gets back to normal instantly. I’m going to set up a second feeder in the house to see if it is purely a location and bad WiFi thing, but this never was a problem for the longest time. I changed from a UniFi gateway to the UDM pro which seems a bizarre cause as the access points have not changed

Just wondering if anyone else is seeing this

8

For probably more than a year now I’ve had problems with my piaware losing WiFi connectivity. It’s headless so the only option is reboot. I’ve written various scripts to ping the router, restart the network or reboot. None of them seemed to solve the issue reliably. So I finally ran an Ethernet cable to the pi and so far so good. I still keep a WiFi connection too, but if it drops it isn’t an issue.

9

Welcome @newtonheath

The most common cause of ‘partial failure’ is a soft PSU.
Don’t trust the claimed specs until you have measured it and remember they die a slow death (just because it was good last year, doesn’t mean it’s still good)