I live in Northern Finland, and since the sky here is not full of planes all the time I get this a lot:
11/10/2014 00:01:15 495 msgs recv'd from dump1090 via faup1090 (0 in last 5m); 634 msgs sent to FlightAware
11/10/2014 00:05:43 no new messages received in 6431 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...
11/10/2014 00:05:43 attempting to restart dump1090 using '/etc/init.d/fadump1090.sh restart'...
Stopping dump1090 server: dump1090/sbin/start-stop-daemon: warning: failed to kill 5061: No such process
.
Starting dump1090 server: dump1090011/10/2014 00:05:45 dump1090 restart appears to have been successful
11/10/2014 00:05:45 sending a hangup signal (SIGHUP) to faup1090 (process 5063) to shut it down...
11/10/2014 00:05:45 the system confirmed that process 5063 exited after receiving a hangup signal
11/10/2014 00:05:45 ADS-B data program 'dump1090' is listening on port 30005, so far so good
11/10/2014 00:05:45 i see nothing serving on port 10001, starting faup1090...
11/10/2014 00:05:45 started faup1090 (process ID 5083)
11/10/2014 00:05:48 connecting to faup1090 on port 10001...
11/10/2014 00:05:48 piaware is connected to faup1090 on port 10001
The longest pause last night was almost 20000 secs.
How can I increase this threshold value?
The proper value for my receiver should be in the order of 8-10 hours to prevent re-start attempts
just because there are no flights going on in the vicinity of my receiver.
Secondly, I’m running dump1090 from MR git, i.e. I’m not using fadump1090.
Luckily, ‘/etc/init.d/fadump1090.sh restart’ does not harm the running dump1090 process,
but piaware re-starting an underlying component sounds a bit odd to me, but I have to say
I’m a newcomer in this ADS-B arena. Maybe this is needed because of unreliable el-cheapo
DVB-T sticks or something, but I’s like to habe control of how often the re-start is attempted,
and also would be nice if piaware was not so completely bind to fadump1090.
The problem is that we’ve faced a lot of situations where dump1090 will stop working due to one reason or another, many of which are unknown. It’s very important that we can detect that we’re not receiving data and try to restart dump1090 to fix the problem.
As a result of this work-around (restarting dump1090), I understand that dump1090 could potentially be restarted unnecessarily if your airspace is really quiet. I guess it’s like the question of if a tree falls in a forest and no one is there – is it possible to know if dump1090 is working if there’s no planes?
Aside from the log message, is there a real downside to how it’s currently implemented? You could certainly edit the source or we could add a configuration option, but I wonder if much is gained?
In theory dump1090 generates empty (all-zeroes) heartbeat messages every 60 seconds by default if there is no other traffic, mostly to keep the TCP connection alive.
I suspect that this is not making it through faup1090 to piaware, as that connection only reports active aircraft; but faup1090 could perhaps be smarter about this and indicate to piaware that, while it has no active aircraft, it did hear a heartbeat message?
What’s the failure mode for dump1090 getting stuck? Does it stop responding entirely, or does it keep running but just fails to hear new messages off the air? Looking for the heartbeat would only help in the first case.
I have the same problem due to low traffic levels in the early morning hours and a nighttime, large aircraft, curfew for the benefit of residents close to our airport.
If you are game:
/usr/lib/piaware/config.tcl contains the following line: set noMessageActionIntervalSeconds 3600
Works OK for me. Change at your own risk.
/tmp/piaware.out messages relating to zero aircraft have changed with version 1.17
