PiAware stopped reporting

FlightAware ADS-B Flight Tracking
1

My PiAware has stopped sending info. It’s running the PiAware distro on a RPi Zero 2 W.

When I check the logs on my ADSB stats page it shows:

[2024-04-23 18:59 BST] attempting to start dump1090-fa using ‘systemctl --no-block restart dump1090-fa.service < /dev/null’…
[2024-04-23 18:59 BST] dump1090 start appears to have been successful
[2024-04-23 18:59 BST] attempting to start dump1090…
[2024-04-23 18:59 BST] no ADS-B data program seen listening on port 30005 for 10 seconds, next check in 60s

I have run all of the commands from the site config, except halt device.

When I attempt to update dump1090 I get:

[2024-04-23 19:03 BST] manual update (user-initiated via their flightaware control page) requested by adept server
[2024-04-23 19:03 BST] performing manual update, action: dump1090 restart_piaware
[2024-04-23 19:03 BST] *** running command ‘/usr/lib/piaware/helpers/run-apt-get update’ and logging output
[2024-04-23 19:03 BST] run-apt-get(4214): Hit:2 http://www.flightaware.com/adsb/piaware/files/packages bullseye InRelease
[2024-04-23 19:03 BST] run-apt-get(4214): Get:3 http://www.flightaware.com/mirror/raspberrypi/debian bullseye InRelease
[2024-04-23 19:03 BST] run-apt-get(4214): Hit:1 http://www.flightaware.com/mirror/raspbian/raspbian bullseye InRelease
[2024-04-23 19:03 BST] 0 msgs recv’d from dump1090 (0 in last 5m); 0 msgs sent to FlightAware
[2024-04-23 19:03 BST] run-apt-get(4214): Reading package lists…
[2024-04-23 19:03 BST] update request complete
[2024-04-23 19:03 BST] run-apt-get(4214): E: Release file for http://flightaware.com/mirror/raspberrypi/debian/dists/bullseye/InRelease is not valid yet (invalid for another 17h 54min 51s). Updates for this repository will not be applied.
[2024-04-23 19:03 BST] skipping action restart_piaware
[2024-04-23 19:03 BST] child process 4214 exited with status EXIT 100
[2024-04-23 19:03 BST] skipping action dump1090

When I attempt to update PiAware I get:

[2024-04-23 19:14 BST] manual update (user-initiated via their flightaware control page) requested by adept server
[2024-04-23 19:14 BST] *** running command ‘/usr/lib/piaware/helpers/run-apt-get update’ and logging output
[2024-04-23 19:14 BST] run-apt-get(4774): Hit:2 http://www.flightaware.com/adsb/piaware/files/packages bullseye InRelease
[2024-04-23 19:14 BST] run-apt-get(4774): Hit:1 http://www.flightaware.com/mirror/raspbian/raspbian bullseye InRelease
[2024-04-23 19:14 BST] run-apt-get(4774): Get:3 http://www.flightaware.com/mirror/raspberrypi/debian bullseye InRelease
[2024-04-23 19:14 BST] no ADS-B data program seen listening on port 30005 for 191 seconds, next check in 60s
[2024-04-23 19:14 BST] run-apt-get(4774): Reading package lists…
[2024-04-23 19:14 BST] skipping action piaware
[2024-04-23 19:14 BST] run-apt-get(4774): E: Release file for http://flightaware.com/mirror/raspberrypi/debian/dists/bullseye/InRelease is not valid yet (invalid for another 17h 43min 10s). Updates for this repository will not be applied.
[2024-04-23 19:14 BST] child process 4774 exited with status EXIT 100
[2024-04-23 19:14 BST] update request complete

Unfortunately, this PiAware is not at my location. It’s on the other side of the continent. If it were local I’d just wipe it out and restart it.

Is there an easy way to repair this installation? I could potentially have someone local SSH in to it, but in order to physically access the RPi I have to be there and that’s a 6+ hours of flying.

2

Did you attempt to reboot the device and not just the process ? Restarting might unblock some underneath hanging process that’s not visible for you yet.
Other option is to view the logging to see what is going on in the system itself.

3

I just managed to arrange to have someone go and pull/replug the power, I’m not sure when they’ll have the chance to do it.

Would the “reboot device” command not accomplish the same thing though?

When I command the reboot it logs:

[2024-04-23 19:57 BST] manual update (user-initiated via their flightaware control page) requested by adept server
[2024-04-23 19:57 BST] rebooting…
[2024-04-23 19:57 BST] update request complete
[2024-04-23 19:57 BST] performing manual update, action: reboot
[2024-04-23 19:57 BST] piaware (process 18665) is shutting down because it received a shutdown signal (SIGTERM) from the system…
[2024-04-23 19:57 BST] piaware (process 18665) is exiting…
[2024-04-23 19:57 BST] site statistics URL: https://flightaware.com/adsb/stats/user/(REDACTED)
[2024-04-23 19:57 BST] my feeder ID is (REDACTED)
[2024-04-23 19:57 BST] adept reported location: (REDACTED)
[2024-04-23 19:57 BST] logged in to FlightAware as user F8Dispatch
[2024-04-23 19:58 BST] 0 msgs recv’d from dump1090; 0 msgs sent to FlightAware

4

Your RPi’s clock’s time and/or timezone is wrongly set which is causing this problem.

set these correctly by following commands;

Time Zone:

sudo dpkg-reconfigure tzdata

Local Time

sudo timedatectl set-time TIME `

In above command, replace TIME by your Local Time hr:min:sec

 

HELP MENU

pi@raspi-3:~ $ sudo timedatectl help
timedatectl [OPTIONS...] COMMAND ...

Query or change system time and date settings.

Commands:
  status                   Show current time settings
  show                     Show properties of systemd-timedated
  set-time TIME            Set system time
  set-timezone ZONE        Set system time zone
  list-timezones           Show known time zones
  set-local-rtc BOOL       Control whether RTC is in local time
  set-ntp BOOL             Enable or disable network time synchronization

systemd-timesyncd Commands:
  timesync-status          Show status of systemd-timesyncd
  show-timesync            Show properties of systemd-timesyncd

Options:
  -h --help                Show this help message
     --version             Show package version
     --no-pager            Do not pipe output into a pager
     --no-ask-password     Do not prompt for password
  -H --host=[USER@]HOST    Operate on remote host
  -M --machine=CONTAINER   Operate on local container
     --adjust-system-clock Adjust system clock when changing local RTC mode
     --monitor             Monitor status of systemd-timesyncd
  -p --property=NAME       Show only properties by this name
  -a --all                 Show all properties, including empty ones
     --value               When showing properties, only print the value

See the timedatectl(1) man page for details.
pi@raspi-3:~ $

 

5

Ah, great. I ran the “sudo /etc/init.d/ntp restart” that the anomaly dialog suggested, but that didn’t do anything. I have minimal understanding of how to do things in linux, if that wasn’t already obvious.

I’ll have someone set the time correctly, but I’m assuming that’s a different problem than the data being sent, as it’s been giving that anomaly warning but has been running fine for weeks.

6

In your earlier screenshots I didn’t encounter the reboot being executed so that’s why I suggested it.

The command does essentially the same indeed but once the connection is established again it should start logging in 5 minute intervals so be patient once restarted.

7

No worries, I was chopping off different parts of the log and I forgot to add the reboot log.

I’ve tried waiting until the inrelease was valid on the mis-set clock as I was hoping an update might pop-up and fix it, but so far nothing. I’ll keep being patient, it’s not like it’s absolutely vital and needs to be up and running ASAP.