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.
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.
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
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:~ $
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.
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.
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.
