Is it just me or does everyone dread initiating updates. I did one recently and now get this status.
got ‘couldn’t open socket: connection refused’
dump1090 is NOT producing data on localhost:30005.
PiAware Status page shows the receiver as offline and red, yet the live map page and my site statistics show live flights.
I also use port 30005 to feed a virtual radar server and populate a basestation style sql3 database all of which are also broken .
Any insights? running on a raspberrypi 3
And the dump1090 logs say… what?
ct 23 15:45:03 piaware piaware[500]: skyaware978 restart appears to have been successful
Oct 23 15:45:27 piaware piaware[500]: no ADS-B data program seen listening on port 30005 for 250 seconds, next check in 60s
Oct 23 15:45:41 piaware piaware[500]: no ADS-B data program is serving on port 30005, not starting multilateration client yet
Oct 23 15:46:27 piaware piaware[500]: no ADS-B data program seen listening on port 30005 for 310 seconds, next check in 60s
Oct 23 15:46:41 piaware piaware[500]: no ADS-B data program is serving on port 30005, not starting multilateration client yet
Oct 23 15:47:06 piaware piaware[500]: 0 msgs recv’d from dump1090 (0 in last 5m); 0 msgs sent to FlightAware
Oct 23 15:47:27 piaware piaware[500]: no ADS-B data program seen listening on port 30005 for 370 seconds, trying to start it…
Oct 23 15:47:27 piaware piaware[500]: attempting to start dump1090…
Oct 23 15:47:27 piaware piaware[500]: attempting to start dump1090-fa using ‘systemctl --no-block restart dump1090-fa.service < /dev/null’…
Oct 23 15:47:27 piaware piaware[500]: dump1090 start appears to have been successful
Oct 23 15:47:37 piaware piaware[500]: no ADS-B data program seen listening on port 30005 for 10 seconds, next check in 60s
Oct 23 15:47:41 piaware piaware[500]: no ADS-B data program is serving on port 30005, not starting multilateration client yet
Oct 23 15:48:37 piaware piaware[500]: no ADS-B data program seen listening on port 30005 for 70 seconds, next check in 60s
Oct 23 15:48:41 piaware piaware[500]: no ADS-B data program is serving on port 30005, not starting multilateration client yet
Oct 23 15:49:38 piaware piaware[500]: no ADS-B data program seen listening on port 30005 for 131 seconds, next check in 60s
No dump1090 logs there. Try journalctl -u dump1090-fa and systemctl status dump1090-fa
After digging around I resolved my issue by modifying the dump1090-fa.service file adding --net to the command line. The original from when I did and apt-update was as follows.
# dump1090-fa service for systemd
[Unit]
Description=dump1090 ADS-B receiver (FlightAware customization)
Documentation=https://flightaware.com/adsb/piaware/
Wants=network.target
After=network.target
[Service]
User=dump1090
RuntimeDirectory=dump1090-fa
RuntimeDirectoryMode=0755
ExecStart=/usr/share/dump1090-fa/start-dump1090-fa --write-json %t/dump1090-fa --quiet
SyslogIdentifier=dump1090-fa
Type=simple
Restart=on-failure
RestartSec=30
RestartPreventExitStatus=64
Nice=-5
[Install]
WantedBy=default.target
The change I made is as follows.
# dump1090-fa service for systemd
[Unit]
Description=dump1090 ADS-B receiver (FlightAware customization)
Documentation=https://flightaware.com/adsb/piaware/
Wants=network.target
After=network.target
[Service]
User=dump1090
RuntimeDirectory=dump1090-fa
RuntimeDirectoryMode=0755
ExecStart=/usr/share/dump1090-fa/start-dump1090-fa --net --write-json %t/dump1090-fa --quiet
SyslogIdentifier=dump1090-fa
Type=simple
Restart=on-failure
RestartSec=30
RestartPreventExitStatus=64
Nice=-5
[Install]
WantedBy=default.target
That doesn’t really make any sense, though - there should be no need to specify --net in there.
What did the dump1090-fa logs say?
What does your /etc/default/dump1090-fa look like? Maybe something went wrong with translating a pre-v5 config file to a v6 config file.
I agree I shouldn’t need to specify --net.
Oct 24 11:13:13 piaware systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
Oct 24 11:13:13 piaware dump1090-fa[18751]: Sun Oct 24 11:13:13 2021 -05 dump1090-fa 3.8.1 starting up.
Oct 24 11:13:13 piaware dump1090-fa[18751]: rtlsdr: using device #0: Generic RTL2832U (Generic, RTL2832U, SN 77771111153705700)
Oct 24 11:13:13 piaware dump1090-fa[18751]: Detached kernel driver
Oct 24 11:13:13 piaware dump1090-fa[18751]: Found Rafael Micro R820T tuner
Oct 24 11:13:13 piaware dump1090-fa[18751]: rtlsdr: tuner gain set to 49.6 dB
Oct 24 11:13:13 piaware dump1090-fa[18751]: Allocating 4 zero-copy buffers
Wait, what? You somehow have completely the wrong binary installed. Should be impossible.
Can you explain what image you started from, how you originally installed dump1090-fa, and how you did the upgrade?
I would try sudo apt-get -f install and see if the package management system wants to fix anything (maybe it got interrupted mid-upgrade)
I started with PiAware (SD Card) 4 and currently show the current status as PiAware (SD Card) 6.1. I ran apt-get -f install and there was nothing that was updated and no warnings of failed installs of any packages.
From the original SD card install I added virtual radar server and the database and admin addon’s. I also added support for a U-Blox AG [u-blox 7] for GPS and timing and Python and the python 10902sql code to independently feed a database separate for other uses mostly to automatically create reports of South American ICAO numbers that have no other associated data so I can try to track down the registrations, owners and aircraft.
I do have auto updates enabled.
sudo piaware-config allow-auto-updates yes
sudo piaware-config allow-manual-updates yes
Can you try an apt-get install --reinstall dump1090-fa ?
One item of note since doing apt-get update in the piaware logfile is with running gpsd for station location there is zero deadband for typical gps accuracy drift.
The end result is dump1090-fa restarts with a .0001 change is degree of either latitude or longitude.
I know this is off track of the current issue but thought I should mention it.
/var/log/piaware.log
Oct 24 05:37:19 piaware piaware[483]: Receiver location changed, restarting dump1090 and skyaware978
Oct 24 05:37:19 piaware piaware[483]: attempting to restart dump1090…
Oct 24 05:37:19 piaware piaware[483]: attempting to restart dump1090-fa using ‘systemctl --no-block try-restart dump1090-fa.service < /dev/null’…
Oct 24 05:37:19 piaware piaware[483]: dump1090 restart appears to have been successful
Oct 24 05:37:19 piaware piaware[483]: attempting to restart skyaware978…
Oct 24 05:37:19 piaware piaware[483]: attempting to restart skyaware978 using ‘systemctl --no-block try-restart skyaware978.service < /dev/null’…
Oct 24 05:37:19 piaware piaware[483]: skyaware978 restart appears to have been successful
Oct 24 05:37:19 piaware piaware[483]: gpsd reported location: -12.06558, -77.09954, 87m (WGS84)
Oct 24 05:37:19 piaware piaware[483]: Receiver location changed, restarting dump1090 and skyaware978
Oct 24 05:37:19 piaware piaware[483]: attempting to restart dump1090…
Oct 24 05:37:19 piaware piaware[483]: attempting to restart dump1090-fa using ‘systemctl --no-block try-restart dump1090-fa.service < /dev/null’…
Oct 24 05:37:19 piaware piaware[483]: dump1090 restart appears to have been successful
Oct 24 05:37:19 piaware piaware[483]: attempting to restart skyaware978…
Oct 24 05:37:19 piaware piaware[483]: attempting to restart skyaware978 using ‘systemctl --no-block try-restart skyaware978.service < /dev/null’…
Oct 24 05:37:19 piaware piaware[483]: skyaware978 restart appears to have been successful
Oct 24 05:37:20 piaware piaware[483]: Receiver location changed, restarting dump1090 and skyaware978
Oct 24 05:37:20 piaware piaware[483]: attempting to restart dump1090…
Oct 24 05:37:20 piaware piaware[483]: attempting to restart dump1090-fa using ‘systemctl --no-block try-restart dump1090-fa.service < /dev/null’…
Oct 24 05:37:20 piaware piaware[483]: dump1090 restart appears to have been successful
Oct 24 05:37:20 piaware piaware[483]: attempting to restart skyaware978…
Oct 24 05:37:20 piaware piaware[483]: attempting to restart skyaware978 using ‘systemctl --no-block try-restart skyaware978.service < /dev/null’…
Oct 24 05:37:20 piaware piaware[483]: skyaware978 restart appears to have been successful
Oct 24 05:37:20 piaware piaware[483]: gpsd reported location: -12.06559, -77.09955, 87m (WGS84)
Oct 24 05:37:20 piaware piaware[483]: Receiver location changed, restarting dump1090 and skyaware978
Oct 24 05:37:20 piaware piaware[483]: attempting to restart dump1090…
Oct 24 05:37:20 piaware piaware[483]: attempting to restart dump1090-fa using ‘systemctl --no-block try-restart dump1090-fa.service < /dev/null’…
Oct 24 05:37:20 piaware piaware[483]: dump1090 restart appears to have been successful
Oct 24 05:37:20 piaware piaware[483]: attempting to restart skyaware978…
Oct 24 05:37:20 piaware piaware[483]: attempting to restart skyaware978 using ‘systemctl --no-block try-restart skyaware978.service < /dev/null’…
Oct 24 05:37:20 piaware piaware[483]: skyaware978 restart appears to have been successful
Oct 24 05:37:21 piaware piaware[483]: Receiver location changed, restarting dump1090 and skyaware978
Oct 24 05:37:21 piaware piaware[483]: attempting to restart dump1090…
Oct 24 05:37:21 piaware piaware[483]: attempting to restart dump1090-fa using ‘systemctl --no-block try-restart dump1090-fa.service < /dev/null’…
Oct 24 05:37:21 piaware piaware[483]: dump1090 restart appears to have been successful
Oct 24 05:37:21 piaware piaware[483]: attempting to restart skyaware978…
Oct 24 05:37:21 piaware piaware[483]: attempting to restart skyaware978 using ‘systemctl --no-block try-restart skyaware978.service < /dev/null’…
Oct 24 05:37:21 piaware piaware[483]: skyaware978 restart appears to have been successful
There is actually a deadband (~ 250m), but I’ve seen problems in the past where gpsd would alternate between reporting a good 3D fix and reporting no position fix, which defeated that logic (it considers a change from “no position info” to “have position info” to be a significant movement). Based on your logs I suspect the same thing is happening on your system.
I wasn’t able to reproduce it with hardware I have here, unfortunately.
(also, this probably explains the constant dump1090 restarts that you’re seeing. Unsurprisingly, dump1090 won’t work so well if it’s being restarted once a second …)
As a workaround you can piaware-config use-gpsd no
I had a recent issue with gpsd reporting fix/no fix quickly. The solution was to update to the latest revision (3.23.1 - IIRC). It turned out the revision i had was ~4yrs old.
Best regards,
Fred
Thanks for the info, I guess I need to site my ublox receivers better. New home so reconnecting and restarting hasn’t been without some issues. I wonder if having a time based deadband along with the existing coordinate deadband would help, though that would probably make a hash of people using them for timing applications. Cause and effect always rears it’s ugly head.
Do you just use GPS or have enabled Galileo, Beidou or Glonass? I have several ublox receivers and have enabled 3 or 4 systems(only version 9 allowed me to enable all four).
My airsquiter with a ublox8 with GPS, Beidou and Glonass enabled, using the attic antenna, usually receives 24 satellites.
It can also depend on the quality of the antenna and it’s location. I have one mounted outside on the chimney, however, the ones in the attic work well.
Oh no…it’s not just you! 
I’ve only recently built up enough confidence to update my other Pi’s without losing sleep over it but when it comes to my Virtual Radar Pi I have to post in numerous forums to bolster my confidence to go ahead and even then it fills me with dread!
This despite my keeping a spare MicroSD Card plugged in and cloning the OS Card onto it before every major update. I know I can revert quickly should it fall over but it doesn’t stop me procrastinating before pushing the button.
I was fretting about the FA v5-6 update for weeks before I noticed the Auto-update toggle was on and it had already updated transparently without my knowledge! 
I do have faith & trust in those God-like beings who develop new versions its just that I don’t have much faith in myself to troubleshoot and resolve any issues that might arise.
That’s why I depend on communities like this and would like to extend my thanks for putting up with the same old questions from me when an update is looming.
It’s a bit like going to the dentist - all that worry up to the time that the deed is done and then feeling foolish afterwards that I was worried about nothing! 
Thanks & kind regards,
-=Glyn=-
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.