I read in the release notes for 1.15 that piaware will attempt to restart dump1090 if no messages have been received for an hour, but I so no sign/log of this in my /tmp/piaware.out file:
10/28/2014 03:49:03 19986 msgs recv’d from dump1090 (24 in last 5m); 20439 msgs sent to FlightAware
10/28/2014 03:54:03 20007 msgs recv’d from dump1090 (21 in last 5m); 20461 msgs sent to FlightAware
10/28/2014 03:59:03 20041 msgs recv’d from dump1090 (34 in last 5m); 20497 msgs sent to FlightAware
10/28/2014 04:04:03 20058 msgs recv’d from dump1090 (17 in last 5m); 20515 msgs sent to FlightAware
10/28/2014 04:09:03 20082 msgs recv’d from dump1090 (24 in last 5m); 20539 msgs sent to FlightAware
10/28/2014 04:14:03 20084 msgs recv’d from dump1090 (2 in last 5m); 20543 msgs sent to FlightAware
10/28/2014 04:17:59 lost connection to faup1090, disconnecting…
10/28/2014 04:18:00 no ADS-B data program is serving on port 30005, next check in 60s
10/28/2014 04:18:38 no ads-b producer (dump1090, modesmixer, etc) appears to be running or is not listening for connections on port 30005, next check in 5m
10/28/2014 04:19:05 no ADS-B data program is serving on port 30005, next check in 60s
10/28/2014 04:19:08 20090 msgs recv’d from dump1090 (6 in last 5m); 20550 msgs sent to FlightAware
…
10/28/2014 05:13:33 no ads-b producer (dump1090, modesmixer, etc) appears to be running or is not listening for connections on port 30005, next check in 5m
10/28/2014 05:14:03 20090 msgs recv’d from dump1090 (0 in last 5m); 20560 msgs sent to FlightAware
10/28/2014 05:14:10 no ADS-B data program is serving on port 30005, next check in 60s
10/28/2014 05:15:10 no ADS-B data program is serving on port 30005, next check in 60s
10/28/2014 05:16:10 no ADS-B data program is serving on port 30005, next check in 60s
10/28/2014 05:17:10 no ADS-B data program is serving on port 30005, next check in 60s
10/28/2014 05:18:10 no ADS-B data program is serving on port 30005, next check in 60s
10/28/2014 05:18:33 no ads-b producer (dump1090, modesmixer, etc) appears to be running or is not listening for connections on port 30005, next check in 5m
10/28/2014 05:19:03 20090 msgs recv’d from dump1090 (0 in last 5m); 20561 msgs sent to FlightAware
10/28/2014 05:19:10 no ADS-B data program is serving on port 30005, next check in 60s
10/28/2014 05:20:11 no ADS-B data program is serving on port 30005, next check in 60s
10/28/2014 05:21:11 no ADS-B data program is serving on port 30005, next check in 60s
10/28/2014 05:22:11 no ADS-B data program is serving on port 30005, next check in 60s
10/28/2014 05:23:11 no ADS-B data program is serving on port 30005, next check in 60s
10/28/2014 05:23:33 no ads-b producer (dump1090, modesmixer, etc) appears to be running or is not listening for connections on port 30005, next check in 5m
and I have to restart dump1090 by:
sudo /etc/init.d/fadump1090.sh start
is there some log? Should I just put dump1090 into inittab with a “respawn” option? I’d really like this to be a hands-off reliable data feed…
Same problem here. As a crude workaround, I’ve added a crontab job that reboots the RaspPi once a day at 3AM. But it would be better if this could be fixed more cleanly…
Do you have dump1090 accessible from the Internet or run any type of security scanning software on your local network? If so, certain requests will make dump1090 crash while everything else on the Pi works. I had that issue and just modified the port forwarding settings so dump1090 is available on (e.g.) port 60000 from the Internet. So far it’s been stable for almost a week.
I have nothing scanning on the local network. The port is redirected through the firewall so that I can access it remotely, though. So outside http get requests to 8080 on my external IP will be redirected from the router through to the RaspberryPi. I can easily stop that redirection, if necessary. Maybe I will do that as a test…
Port 8080 is commonly used by proxy servers, and in my logs I see quite a lot of scanning from outside on this port. Probably automated proxy-finders or something. That’s why I have my dump1090 web interface on another port.
dump1090 still segfaults once every two or three days or so, but I have a script in crontab to relaunch it if it dies. I don’t know the reason, however I don’t think it’s related to unexpected web requests, though that’s just my guess.
Are you ‘hardwire’ to the LAN or using a WiFi dongle? Several (me included) have seen issues running with a WiFi dongle. Once I switch to hardwired even thing was solid as a rock. Could be something to consider.
I indeed was port forwarding outside 8080 to inside 8080 (so I could watch the planes while at work! ).
Based on reports here I will move that to a port other than 8080… but I guess a monitor/restart is in my future to make this reliable.
Is there a place to send cores/backtraces (assuming I enable cores…)
Some of the new modifications to MalcolmRobb’s branch (which flightaware’s dump1090 is based on) may have fixed this. The pull was merged to MalcolmRobb’s branch, however, the latest changes have not been pulled yet into flightaware dump1090.
See the pull request linked above for more details; note, however, that this may not be the reason why it is stopping to work for you after a day. The reason I think this may be the problem is because I usually have the web interface open, and until running dump1090 with this code, the web interface would stop working, and dump1090 would stop accepting any new socket connections, after around a day. The problem was, that dump1090 was not closing network file descriptors, so every new connection used up a connection against the limit, even after it was closed.
So, maybe try running MalcolmRobb’s branch separately; or open a few tabs of the web interface (or make lots of new network connections to dump1090) and see if it crashes any faster.
).