PIAware issue

FlightAware ADS-B Flight Tracking
1

I’m unsure as to where to put this however I wakeup to notifications that my Raspberry Pi stops sending data, look and it says the following on SUDO PIAWARE-STATUS:
dump1090 is running.
faup1090 is not running.
piaware is not running.
dump1090 is listening for connections on port 30005.
no program appears to be listening for connections on port 10001.
piaware is NOT connected to port 10001.
piaware is NOT connected to FlightAware.
got ‘couldn’t open socket: connection refused’
dump1090 is NOT producing data on port 10001.
dump1090 is producing data on port 30005.

So I try restarting piaware, unfortunately it doesn’t go… I have to reboot the whole PI and try again and it’s done this two nights in a row at pretty much the same time (around 3AM GMT). I have tried viewing the log however by the time I’ve restarted and “ran tail -f /tmp/piaware.out” it just has fresh data and there’s nothing in “/var/log/”. I’m unsure why it’s happening or what’s causing it but it’s an issue I wish to fix.

Help! It’d be great if there was a way once it stopped working it could just reboot the right processes somehow? I tried the following and it still didn’t fix it until reboot. The live RADAR URL is http://radar.bandwidth.pl:8080 it runs fine although it does keep getting issues.

sudo service piaware restart
./dump1090 --interactive --net
sudo piaware-status

& To rule out my internet being an issue, it’s never touched and is online 24/7;

750×400 28.1 KB

I’d appreciate any help anyone has to give, I rate my Linux skill at about 7/10 although I haven’t used Debian before so 4/10 for Debian alone. - Can’t figure it out!

2

Rebooting will wipe /tmp; try looking at /tmp/piaware.out after it’s broken, but before you restart piaware or reboot.
It looks like faup1090 is dying for some reason and not being restarted, but the log should have more clues.

3

I read faup1090 wasn’t required, it’s never been running ever since I’ve started and it’s all been fine?

Like now, it’s working completely fine after reboot;
pi@Radar ~ $ sudo piaware-status
dump1090 is running.
faup1090 is not running.
piaware is running.
dump1090 is listening for connections on port 30005.
dump1090 is listening for connections on port 10001.
piaware is connected to port 10001.
piaware is connected to FlightAware.
dump1090 is producing data on port 30005.
dump1090 is producing data on port 10001.

4

Ah, ok, that’s… very weird. If you’re running FlightAware’s dump1090 then you’re correct, you don’t need faup1090 because dump1090 will be listening on both 30005 and 10001. (faup1090 is used to bridge between a non-flightaware dump1090 producing data on port 30005, and piaware which wants data in the flightaware format on port 10001)

But in your example where it’s broken, dump1090 is allegedly listening only on 30005; I don’t understand how a previously-working FlightAware dump1090 would ever get in that state.

Do you by any chance have a second version of dump1090 installed that could be getting started by accident?

I notice you mentioned running dump1090 by hand with --interactive --net; that’s going to interfere if it starts before the “main” dump1090 does as it will grab the SDR dongle and network ports, you don’t really want to be doing that. Try “view1090” if you just want to see the data from an already-running dump1090, that won’t interfere.

5

Honestly I wouldn’t be able to look and see where my other dump1090 would be, I have got Flightradar24’s broadcaster which has apparently got it’s own Dump which may explain why Flightradar’s statistics said my PI never went down? ‘UP’ 100% apparently. Although I would be unsure how to disable this.

So to run Dump you put “view1090”? I wasn’t sure if DUMP was running, I don’t believe it is running unless I use --interactive --net?

So DUMP isn’t meant to run on 30005 too?

Thanks,

6

Yeah, OK, fr24’s feeder will be interfering, it likes to start a copy of dump1090 and then it becomes a race to see who gets there first.

What you want is probably:

  • FlightAware’s dump1090 running and listening on ports 30005 and 10001
  • piaware connected to port 10001 for data
  • fr24feed connected to port 30005 for data
  • fr24feed’s copy of dump1090 not running

“view1090” is a utility that connects to an existing running dump1090 and shows you the text-mode interactive display.

To disable fr24feed’s copy of dump1090, assuming you are using the newer beta feeder:

  • Configure it for a “Beast TCP” connection to 127.0.0.1:30005
  • Disable raw and basestation output

Your /etc/fr24feed.ini should look like this:



receiver="beast-tcp"
host="127.0.0.1:30005"
bs="no"
raw="no"
... other stuff e.g. your fr24 key ...

edit: FlightAware’s copy of dump1090 is usually configured to start on boot, or will be started by piaware if it’s not running for a while. You should not need to manually start it.

7

I presume to have;

  • FlightAware’s dump1090 running and listening on ports 30005 and 10001
  • piaware connected to port 10001 for data
  • fr24feed connected to port 30005 for data
  • fr24feed’s copy of dump1090 not running

I need to do what you said, my previous fr24.ini


receiver="avr-tcp"
fr24key="******************"
host="localhost:30002"
path="/usr/lib/fr24/dump1090"
bs="yes"
raw="no"
logmode="1"
windowmode="0"
logpath="/var/log/"
mpx="no"

now:


receiver="avr-tcp"
fr24key="399668d58de2fd21"
host="localhost:30005"
path="/usr/lib/fr24/dump1090"
bs="no"
raw="no"
logmode="1"
windowmode="0"
logpath="/var/log/"
mpx="no"

Should I change the receiver type or leave it?
Should I also remove “path”?

/ restart the service or just reboot the PI

It now shows the PI on FR24 being ‘OFFLINE’ and it seems there’s something running on 30002, 30005.

http://puu.sh/fhhwV/6cc39594c2.png

8

I’ve removed “./dump1090 --interactive --net” from my own boot sequence. - as it appears dump1090 is already running on startup but piaware isn’t.
So I have to sudo service piaware restart for that to activate.

I changed it to BEAST-TCP and FR24 Is now picking up aircraft again, changed the port to 30005 and I don’t believe there’s anything running on 30002 anymore - or if there is nothing’s using it.

In addition is there a way to see what’s running on startup and create my own startup sequence because it appears piaware is ran on boot but only dump1090 starts I think? + FR24FEED runs on startup too - useless without piaware running.

Thanks,
Matthew

9

Yes you probably need to remove that “path” setting from fr24feed.

“avr-tcp” will need port 30002; use “beast-tcp” for port 30005. Either combination should work (but not a cross-combination - the receiver type must match the format being produced)

In terms of what gets run on startup - that’s controlled by the symlinks in /etc/rc*.d (and there might be something running out of /etc/rc.local). Too detailed to get into here - google for “sysvinit”. What’s been enabled depends very much on what sdcard image you started from, and what packages you have subsequently installed. Sorry - you’ll have to work this one out yourself. Looking at ‘ps auwxf’ output will let you see exactly what’s running at a point in time.

“update-rc.d piaware defaults” should fix any missing piaware symlinks so it starts on startup. (If you’re familiar with the sysvinit scripts of Redhat et all, “update-rc.d” is roughly the Debian equivalent of “chkconfig”)

10

Removed it as such, I’ve noticed but any FlyBe aircraft never picks up the ‘Speed’ and therefore never plots it on the map? Not sure if this is just me or everyone but it seems to only be FlyBe, there is the odd aircraft that doesn’t go green but most do.

I’ve looked into startup and ran the command as so, with the following response so I presume all is O.K

pi@Radar ~ $ sudo update-rc.d piaware defaults
update-rc.d: using dependency based boot sequencing
insserv: script dump1090.sh: service dump1090 already provided!

I only think this, FR24Feed run on startup so that should be fine.
Would be great if there was a way for it to restart the process on crashing or something though, gah ah well!

Thanks for the help :slight_smile:

11

Well, no idea what’s actually crashing here, there are a lot of moving parts in your setup!
If you can look at the piaware logfile in /tmp next time it has problems, before restarting anything, that’ll help narrow down the cause.
Nothing should be crashing…

12

Seems to be fine, it seems to crash around 3AM so we’ll see if it can make it past 3AM… it has once, which was after the first day I got it all working so it’d be interesting to see if it does the same tonight or whether I’ll wakeup to the same downtime email.
I’ll look at the log next time it crashes, however it seems to be alright at the moment

13

Looked as my PI was last seen updating information 2hr ago (Today and not live)-
pi@Radar ~ $ sudo piaware-status
dump1090 is running.
faup1090 is not running.
piaware is running.
dump1090 is listening for connections on port 30005.
no program appears to be listening for connections on port 10001.
piaware is NOT connected to port 10001.
piaware is connected to FlightAware.
got ‘couldn’t open socket: connection refused’
dump1090 is NOT producing data on port 10001.
dump1090 is producing data on port 30005.

I’ve attached the log file from /tmp OBJ. Sorry it might be a bit long.

02/01/2015 00:03:07 seconds since last message or startup (3229) less than threshold for action (3600), waiting…
02/01/2015 00:03:07 dump1090 is listening for connections on FA-style port 10001
02/01/2015 00:03:37 5397 msgs recv’d from dump1090 (0 in last 5m); 5396 msgs sent to FlightAware
02/01/2015 00:08:07 seconds since last message or startup (3529) less than threshold for action (3600), waiting…
02/01/2015 00:08:07 dump1090 is listening for connections on FA-style port 10001
02/01/2015 00:08:37 5397 msgs recv’d from dump1090 (0 in last 5m); 5396 msgs sent to FlightAware
02/01/2015 00:13:07 dump1090 is listening for connections on FA-style port 10001
02/01/2015 00:13:37 5397 msgs recv’d from dump1090 (0 in last 5m); 5396 msgs sent to FlightAware
02/01/2015 00:18:07 no new messages received in 4129 seconds, it might just be that there haven’t been any aircraft nearby but I’m going to try to restart dump1090, possibly restart faup1090 and definitely reconnect, just in case…
02/01/2015 00:18:07 warning, more than one dump1090 script in /etc/init.d, proceeding with ‘/etc/init.d/dump1090.sh’…
02/01/2015 00:18:07 attempting to restart dump1090 using ‘/etc/init.d/dump1090.sh restart’…
dump1090 is running
dump1090 stopped
dump1090 started
02/01/2015 00:18:07 dump1090 restart appears to have been successful
02/01/2015 00:18:07 stop_faup1090: no need to stop faup1090, it’s not running
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected)
02/01/2015 00:18:08 no ADS-B data program is serving on port 30005, next check in 60s
Found Rafael Micro R820T tuner
Max available gain is: 49.60
Setting gain to: 49.60
Exact sample rate is: 2000000.052982 Hz
Gain reported by device: 49.60
02/01/2015 00:18:37 5397 msgs recv’d from dump1090 (0 in last 5m); 5396 msgs sent to FlightAware
02/01/2015 00:19:08 ADS-B data program ‘dump1090’ is listening on port 30005, so far so good
02/01/2015 00:19:08 i see nothing serving on port 10001, starting faup1090…
couldn’t execute “/usr/bin/faup1090”: no such file or directory
while executing
“exec /usr/bin/faup1090 &”
(procedure “start_faup1090” line 2)
invoked from within
“start_faup1090”
(procedure “connect_fa_style_adsb_port” line 19)
invoked from within
“connect_fa_style_adsb_port”
(“after” script)
02/01/2015 00:23:07 no new messages received in 4429 seconds, it might just be that there haven’t been any aircraft nearby but I’m going to try to restart dump1090, possibly restart faup1090 and definitely reconnect, just in case…
02/01/2015 00:23:07 warning, more than one dump1090 script in /etc/init.d, proceeding with ‘/etc/init.d/dump1090.sh’…
02/01/2015 00:23:07 attempting to restart dump1090 using ‘/etc/init.d/dump1090.sh restart’…
dump1090 is running
dump1090 stopped
dump1090 started
02/01/2015 00:23:07 dump1090 restart appears to have been successful
02/01/2015 00:23:07 stop_faup1090: no need to stop faup1090, it’s not running
02/01/2015 00:23:07 close_faup1090_socket called with no socket argument and no faup1090 global socket
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected)
02/01/2015 00:23:08 no ADS-B data program is serving on port 30005, next check in 60s
Found Rafael Micro R820T tuner
Max available gain is: 49.60
Setting gain to: 49.60
Exact sample rate is: 2000000.052982 Hz
Gain reported by device: 49.60
02/01/2015 00:23:37 5397 msgs recv’d from dump1090 (0 in last 5m); 5396 msgs sent to FlightAware
02/01/2015 00:24:08 ADS-B data program ‘dump1090’ is listening on port 30005, so far so good
02/01/2015 00:24:08 i see nothing serving on port 10001, starting faup1090…
couldn’t execute “/usr/bin/faup1090”: no such file or directory
while executing
“exec /usr/bin/faup1090 &”
(procedure “start_faup1090” line 2)
invoked from within
“start_faup1090”
(procedure “connect_fa_style_adsb_port” line 19)
invoked from within
“connect_fa_style_adsb_port”
(“after” script)
02/01/2015 00:28:07 no new messages received in 4729 seconds, it might just be that there haven’t been any aircraft nearby but I’m going to try to restart dump1090, possibly restart faup1090 and definitely reconnect, just in case…
02/01/2015 00:28:07 warning, more than one dump1090 script in /etc/init.d, proceeding with ‘/etc/init.d/dump1090.sh’…
02/01/2015 00:28:07 attempting to restart dump1090 using ‘/etc/init.d/dump1090.sh restart’…
dump1090 is running
dump1090 stopped
dump1090 started
02/01/2015 00:28:07 dump1090 restart appears to have been successful
02/01/2015 00:28:07 stop_faup1090: no need to stop faup1090, it’s not running
02/01/2015 00:28:07 close_faup1090_socket called with no socket argument and no faup1090 global socket
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected)
02/01/2015 00:28:08 no ADS-B data program is serving on port 30005, next check in 60s
Found Rafael Micro R820T tuner
Max available gain is: 49.60
Setting gain to: 49.60
Exact sample rate is: 2000000.052982 Hz
Gain reported by device: 49.60
02/01/2015 00:28:37 5397 msgs recv’d from dump1090 (0 in last 5m); 5396 msgs sent to FlightAware
02/01/2015 00:29:08 ADS-B data program ‘dump1090’ is listening on port 30005, so far so good
02/01/2015 00:29:08 i see nothing serving on port 10001, starting faup1090…
couldn’t execute “/usr/bin/faup1090”: no such file or directory
while executing
“exec /usr/bin/faup1090 &”
(procedure “start_faup1090” line 2)
invoked from within
“start_faup1090”
(procedure “connect_fa_style_adsb_port” line 19)
invoked from within
“connect_fa_style_adsb_port”
(“after” script)
02/01/2015 00:33:07 no new messages received in 5029 seconds, it might just be that there haven’t been any aircraft nearby but I’m going to try to restart dump1090, possibly restart faup1090 and definitely reconnect, just in case…
02/01/2015 00:33:07 warning, more than one dump1090 script in /etc/init.d, proceeding with ‘/etc/init.d/dump1090.sh’…
02/01/2015 00:33:07 attempting to restart dump1090 using ‘/etc/init.d/dump1090.sh restart’…
dump1090 is running
dump1090 stopped
dump1090 started
02/01/2015 00:33:07 dump1090 restart appears to have been successful
02/01/2015 00:33:07 stop_faup1090: no need to stop faup1090, it’s not running
02/01/2015 00:33:07 close_faup1090_socket called with no socket argument and no faup1090 global socket
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected)
Found Rafael Micro R820T tuner
02/01/2015 00:33:08 no ADS-B data program is serving on port 30005, next check in 60s
Max available gain is: 49.60
Setting gain to: 49.60
Exact sample rate is: 2000000.052982 Hz
Gain reported by device: 49.60
02/01/2015 00:33:37 5397 msgs recv’d from dump1090 (0 in last 5m); 5396 msgs sent to FlightAware
02/01/2015 00:34:08 ADS-B data program ‘dump1090’ is listening on port 30005, so far so good
02/01/2015 00:34:08 i see nothing serving on port 10001, starting faup1090…
couldn’t execute “/usr/bin/faup1090”: no such file or directory
while executing
“exec /usr/bin/faup1090 &”
(procedure “start_faup1090” line 2)
invoked from within
“start_faup1090”
(procedure “connect_fa_style_adsb_port” line 19)
invoked from within
“connect_fa_style_adsb_port”
(“after” script)
02/01/2015 00:38:07 no new messages received in 5329 seconds, it might just be that there haven’t been any aircraft nearby but I’m going to try to restart dump1090, possibly restart faup1090 and definitely reconnect, just in case…
02/01/2015 00:38:07 warning, more than one dump1090 script in /etc/init.d, proceeding with ‘/etc/init.d/dump1090.sh’…
02/01/2015 00:38:07 attempting to restart dump1090 using ‘/etc/init.d/dump1090.sh restart’…
dump1090 is running
dump1090 stopped
dump1090 started
02/01/2015 00:38:07 dump1090 restart appears to have been successful
02/01/2015 00:38:07 stop_faup1090: no need to stop faup1090, it’s not running
02/01/2015 00:38:07 close_faup1090_socket called with no socket argument and no faup1090 global socket
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected)
02/01/2015 00:38:08 no ADS-B data program is serving on port 30005, next check in 60s
Found Rafael Micro R820T tuner
Max available gain is: 49.60
Setting gain to: 49.60
Exact sample rate is: 2000000.052982 Hz
Gain reported by device: 49.60
02/01/2015 00:38:37 5397 msgs recv’d from dump1090 (0 in last 5m); 5396 msgs sent to FlightAware
02/01/2015 00:39:08 ADS-B data program ‘dump1090’ is listening on port 30005, so far so good
02/01/2015 00:39:08 i see nothing serving on port 10001, starting faup1090…
couldn’t execute “/usr/bin/faup1090”: no such file or directory
while executing
“exec /usr/bin/faup1090 &”
(procedure “start_faup1090” line 2)
invoked from within
“start_faup1090”
(procedure “connect_fa_style_adsb_port” line 19)
invoked from within
“connect_fa_style_adsb_port”
(“after” script)
02/01/2015 00:43:07 no new messages received in 5629 seconds, it might just be that there haven’t been any aircraft nearby but I’m going to try to restart dump1090, possibly restart faup1090 and definitely reconnect, just in case…
02/01/2015 00:43:07 warning, more than one dump1090 script in /etc/init.d, proceeding with ‘/etc/init.d/dump1090.sh’…
02/01/2015 00:43:07 attempting to restart dump1090 using ‘/etc/init.d/dump1090.sh restart’…
dump1090 is running
dump1090 stopped
dump1090 started
02/01/2015 00:43:07 dump1090 restart appears to have been successful
02/01/2015 00:43:07 stop_faup1090: no need to stop faup1090, it’s not running
02/01/2015 00:43:07 close_faup1090_socket called with no socket argument and no faup1090 global socket
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected)
02/01/2015 00:43:08 no ADS-B data program is serving on port 30005, next check in 60s
Found Rafael Micro R820T tuner
Max available gain is: 49.60
Setting gain to: 49.60
Exact sample rate is: 2000000.052982 Hz
Gain reported by device: 49.60
02/01/2015 00:43:37 5397 msgs recv’d from dump1090 (0 in last 5m); 5396 msgs sent to FlightAware
02/01/2015 00:44:08 ADS-B data program ‘dump1090’ is listening on port 30005, so far so good
02/01/2015 00:44:08 i see nothing serving on port 10001, starting faup1090…
couldn’t execute “/usr/bin/faup1090”: no such file or directory
while executing
“exec /usr/bin/faup1090 &”
(procedure “start_faup1090” line 2)
invoked from within
“start_faup1090”
(procedure “connect_fa_style_adsb_port” line 19)
invoked from within
“connect_fa_style_adsb_port”
(“after” script)
02/01/2015 00:48:07 no new messages received in 5929 seconds, it might just be that there haven’t been any aircraft nearby but I’m going to try to restart dump1090, possibly restart faup1090 and definitely reconnect, just in case…
02/01/2015 00:48:07 warning, more than one dump1090 script in /etc/init.d, proceeding with ‘/etc/init.d/dump1090.sh’…
02/01/2015 00:48:07 attempting to restart dump1090 using ‘/etc/init.d/dump1090.sh restart’…
dump1090 is running
dump1090 stopped
dump1090 started
02/01/2015 00:48:07 dump1090 restart appears to have been successful
02/01/2015 00:48:07 stop_faup1090: no need to stop faup1090, it’s not running
02/01/2015 00:48:07 close_faup1090_socket called with no socket argument and no faup1090 global socket
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected)
02/01/2015 00:48:08 no ADS-B data program is serving on port 30005, next check in 60s
Found Rafael Micro R820T tuner
Max available gain is: 49.60
Setting gain to: 49.60
Exact sample rate is: 2000000.052982 Hz
Gain reported by device: 49.60
02/01/2015 00:48:37 5397 msgs recv’d from dump1090 (0 in last 5m); 5396 msgs sent to FlightAware
02/01/2015 00:49:08 ADS-B data program ‘dump1090’ is listening on port 30005, so far so good
02/01/2015 00:49:08 i see nothing serving on port 10001, starting faup1090…
couldn’t execute “/usr/bin/faup1090”: no such file or directory
while executing
“exec /usr/bin/faup1090 &”
(procedure “start_faup1090” line 2)
invoked from within
“start_faup1090”
(procedure “connect_fa_style_adsb_port” line 19)
invoked from within
“connect_fa_style_adsb_port”
(“after” script)

I went into /etc/init.d/ and removed with “rm -f -r dump1090.sh” as I presume fadump is FlightAware’s copy.

14

Yep, that is probably the right solution; piaware is getting confused by having more than one script that looks like a dump1090 script and chooses the wrong one, presumably the one it picked was starting some other version of dump1090 which is not the FlightAware one. So faup1090 is needed. And then faup1090 fails because it’s missing, I guess because if you started from a FlightAware image then there was no reason for that image to have it installed…

The restart that set it all off is piaware trying to give dump1090 a kick because there was no traffic (which could mean that dump1090 is stuck, although at 1am it’s probably more that there just isn’t any traffic to hear). And then it all turns to custard :wink:

Ah well. Hopefully problem solved!