Raspberry pi feeding software automatic exit

[YsMilan]

Raspberry pi feeding software automatic exit

My radar is T-ZPPP13,Run on the raspberry.ver is 1.0.18-9.
In recent weeks, the software exits automatically after running several hours:
1.PNG
I looked at the log file, but I couldn't find any error messages, and I tried to run on a new RaspberryPi-3, that still doesn't solve the problem.

Log files when software exits automatically：

2017-07-06 14:17:00 | [feed][i]sent 3,0 AC
2017-07-06 14:17:02 | [mlat][i]Pinging the server
2017-07-06 14:17:02 | [mlat][i]Stats 278945/0
2017-07-06 14:17:05 | [feed][i]sent 4,0 AC
2017-07-06 14:17:10 | [feed][i]sent 3,0 AC
2017-07-06 14:17:15 | [feed][n]syncing stream: timeout
2017-07-06 14:17:15 | [feed][i]sent 4,0 AC
2017-07-06 14:17:15 | [feed][n]disconnected
2017-07-06 14:17:15 | [feed][n]waiting 9 seconds
2017-07-06 14:17:24 | [feed][n]ZPPP13@83.140.21.112:28099/UDP
2017-07-06 14:17:24 | [feed][n]connecting
2017-07-06 14:17:31 | [mlat][i]Pinging the server
2017-07-06 14:17:31 | [mlat][i]Stats 278945/0
2017-07-06 14:17:33 | [mlat][i]Received ADS-B time references AC:
2017-07-06 14:17:33 | [mlat][i] 04004C
2017-07-06 14:17:33 | [mlat][i] 780E7F
2017-07-06 14:17:33 | [mlat][i] 780FF6
2017-07-06 14:17:40 | [mlat][i]Pinging the server
2017-07-06 14:17:40 | [mlat][i]Stats 278945/0
2017-07-06 14:17:44 | [feed][n]connected via TCP (fd -1)
2017-07-06 14:17:44 | [feed][n]working

Use “service Fr24feed status" command,The service exited:

pi@raspberrypi:~$ sudo service fr24feed status
  fr24feed.service - LSB: Flightradar24 Decoder & Feeder
   Loaded: loaded (/etc/init.d/fr24feed)
   Active: active (exited) since 2017-07-06 09:55:12 CST; 5h 43min ago
  Process: 536 ExecStart=/etc/init.d/fr24feed start (code=exited, status=0/SUCCESS)

7月 06 09:55:12 raspberrypi fr24feed[536]: Starting FR24 feeder: fr24feed.
7月 06 09:55:12 raspberrypi systemd[1]: Started LSB: Flightradar24 Decoder ....
Hint: Some lines were ellipsized, use -l to show in full.
pi@raspberrypi:~$

[Oblivian]

Why are you using it with Raspberry Pi? Pi is the most complicated device that I have ever came across with.

This, and questions on why to use an airband scanner. Yet talk about an anteanna for just such things. I question your motive or if you are here with good intention.

[YsMilan]

Can you provide an old version of the software? The problem is recent, and the previous software worked very well.

[YsMilan]

I reported this problem on 2017-07-06:

https://forum.flightradar24.com/threads/11186-Raspberry-pi-feeding-software-automatic-exit

After that, the situation has been greatly improved,The problem is only occasionally.
But in the last week, the situation has become serious again. The suddenly terminating is at least 2 times a day.
I also use the AVR-TCP mode，No error information was found in the log file，But I noticed that the records were very similar every time the exception was suddenly terminating：
2017-07-06 14:17:40 | [mlat][i]Pinging the server
2017-07-06 14:17:40 | [mlat][i]Stats 278945/0
2017-07-06 14:17:44 | [feed][n]connected via TCP (fd -1)
2017-07-06 14:17:44 | [feed][n]working

2018-01-13 17:31:13 | [mlat][i]Pinging the server
2018-01-13 17:31:14 | [mlat][i]Stats 867563/107
2018-01-13 17:31:26 | [feed][n]connected via TCP (fd -1)
2018-01-13 17:31:26 | [feed][n]working

The last two Log are the same ，It seems that the program occurs when the TCP is connected，I guess.

[Oblivian]

I reported this problem on 2017-07-06:

https://forum.flightradar24.com/threads/11186-Raspberry-pi-feeding-software-automatic-exit

After that, the situation has been greatly improved,The problem is only occasionally.
But in the last week, the situation has become serious again. The suddenly terminating is at least 2 times a day.
I also use the AVR-TCP mode，No error information was found in the log file，But I noticed that the records were very similar every time the exception was suddenly terminating：
2017-07-06 14:17:40 | [mlat][i]Pinging the server
2017-07-06 14:17:40 | [mlat][i]Stats 278945/0
2017-07-06 14:17:44 | [feed][n]connected via TCP (fd -1)
2017-07-06 14:17:44 | [feed][n]working

2018-01-13 17:31:13 | [mlat][i]Pinging the server
2018-01-13 17:31:14 | [mlat][i]Stats 867563/107
2018-01-13 17:31:26 | [feed][n]connected via TCP (fd -1)
2018-01-13 17:31:26 | [feed][n]working

The last two Log are the same ，It seems that the program occurs when the TCP is connected，I guess.

Do you feed other feeders and they work OK? or just FR24feed

Because this thread was started about FR24feed being the ONLY feeder of many and actually showing an error

2017-10-21 11:31:25 | [reader][i]Connecting to DVBT-TCP-BEAST-RAW receiver via (tcp://localhost:30005)
2017-10-21 11:31:25 | [reader][e]Could not connect to tcp://localhost:30005

While others OK. Which can also be Dump1090 denying connections

So if you do not see the above error, it is not really as simple as saying 'same problem' here.

But even in original post, you did not say what device, what Dump1090 version. Or how it was installed. But do say it does it on 2 RPi devices?, which may be an external issue like the type of stick.

With only 4 reports so far. More information would be required for the developers to even consider to replicate (they do not frequent the forums and email is meant to be used as primary).

It is like going to a doctor and seeing someone walk out coughing with a prescription. Saying 'I have the same as that person, please give the the same solution/drugs', when the symptoms may not be the exactly the same so the the solution can be wrong.

[YsMilan]

Do you feed other feeders and they work OK? or just FR24feed

Because this thread was started about FR24feed being the ONLY feeder of many and actually showing an error

2017-10-21 11:31:25 | [reader][i]Connecting to DVBT-TCP-BEAST-RAW receiver via (tcp://localhost:30005)
2017-10-21 11:31:25 | [reader][e]Could not connect to tcp://localhost:30005

While others OK. Which can also be Dump1090 denying connections

So if you do not see the above error, it is not really as simple as saying 'same problem' here.

But even in original post, you did not say what device, what Dump1090 version. Or how it was installed. But do say it does it on 2 RPi devices?, which may be an external issue like the type of stick.

With only 4 reports so far. More information would be required for the developers to even consider to replicate (they do not frequent the forums and email is meant to be used as primary).

It is like going to a doctor and seeing someone walk out coughing with a prescription. Saying 'I have the same as that person, please give the the same solution/drugs', when the symptoms may not be the exactly the same so the the solution can be wrong.

The data provider is the FlightFeeder of FlightAware:

Using Ethernet connections：
“ADS-B/Mode-S Data Output for Optional Application Integration and Data Feeds
TCP port 30002 for raw/unparsed messages in AVR format”
---for http://flightaware.com/adsb/flightfeeder/

I have two FlightAware FlightFeeder, they have been working all the time ,and the other is providing data to FR24（T-ZPPP7), and everything is normal, and the difference is that the FR24feed it runs is the Windows version.

[Oblivian]

So what is the setting in FR24feed you are using.

What is the error when it exits

Does it come back itself

What does the screen output say when first starting

[YsMilan]

So what is the setting in FR24feed you are using.

What is the error when it exits

Does it come back itself

What does the screen output say when first starting

pi@raspberrypi:~$ cat /etc/fr24feed.ini
receiver="avr-tcp"
fr24key="c4bdc611dcf77176"
host="192.168.1.15:30002"
bs="no"
raw="no"
logmode="1"
procargs="--net --net-http-port 8070"
windowmode="0"
mpx="no"
mlat="yes"
mlat-without-gps="yes"

When it exits,I can't see any wrong information,and it won't come back.

Starting information:

pi@raspberrypi:~$ sudo service fr24feed restart
tail -f /var/log/fr24feed.log
pi@raspberrypi:~$ tail -f /var/log/fr24feed.log
2018-01-14 15:31:30 | [feed][n]busy
2018-01-14 15:31:30 | [feed][n]disconnected
2018-01-14 15:31:30 | [feed][x]Feeding thread terminated
2018-01-14 15:31:32 | [httpd][d]Master thread terminated
2018-01-14 15:31:32 | [main][i]FR24 Feeder/Decoder
2018-01-14 15:31:32 | [main][i]Version: 1.0.18-9/generic
2018-01-14 15:31:32 | [main][i]Built on Apr 20 2017 09:25:30 (T201704200925/Linux/static_arm)
2018-01-14 15:31:32 | [main][i]Copyright 2012-2017 Flightradar24 AB
2018-01-14 15:31:32 | [main][i]http://flightradar24.com
2018-01-14 15:31:32 | [main][i]DNS mode: PING
2018-01-14 15:31:32 | [main][i]Automatic updates are DISABLED
2018-01-14 15:31:32 | [httpd][i]Server started, listening on 0.0.0.0:8754
2018-01-14 15:31:32 | [main][i]Reader thread started
2018-01-14 15:31:32 | [master][i]Starting processing thread
2018-01-14 15:31:32 | [main][i]MLAT data feed started
2018-01-14 15:31:32 | [reader][i]Initializing reader
2018-01-14 15:31:32 | [reader][i]Connecting to AVR-TCP receiver via (avr-tcp://192.168.1.15:30002)
2018-01-14 15:31:32 | [mlat][i]Waiting for MLAT configuration
2018-01-14 15:31:32 | [reader][i]Connected to the receiver, configuring
2018-01-14 15:31:32 | [reader][i]Configured, processing messages
2018-01-14 15:31:33 | [reader][w]Setting new UTC offset: 0!
2018-01-14 15:31:33 | [time][i]Synchronizing time via NTP
2018-01-14 15:32:33 | [time][i]Time synchronized correctly, offset -0.0016 seconds
2018-01-14 15:32:33 | [main][i]Feed Network client started
2018-01-14 15:32:33 | [feed][i]Downloading configuration
2018-01-14 15:32:35 | [feed][c]Interval: 5s
2018-01-14 15:32:35 | [feed][c]Latitude: 25.0539
2018-01-14 15:32:35 | [feed][c]Longitude: 102.7590
2018-01-14 15:32:35 | [feed][c]GND: YES
2018-01-14 15:32:35 | [feed][c]NonADSB: YES
2018-01-14 15:32:35 | [feed][c]Timestamps: optional
2018-01-14 15:32:35 | [feed][c]Max range AIR: 350.0nm
2018-01-14 15:32:35 | [feed][c]Max range GND: 100.0nm
2018-01-14 15:32:35 | [feed][i]defined 5 servers
2018-01-14 15:32:35 | [feed][n]ZPPP13@83.140.21.68:8099/UDP
2018-01-14 15:32:35 | [stats][i]Stats thread started
2018-01-14 15:32:35 | [feed][n]connecting
2018-01-14 15:32:35 | [feed][n]connected via UDP (fd 10)
2018-01-14 15:32:35 | [feed][n]working
2018-01-14 15:32:35 | [feed][i]sent 1,0 AC
2018-01-14 15:32:35 | [mlat][i]MLAT configuration received, service ENABLED
2018-01-14 15:32:35 | [mlat][i]Starting MLAT with preconfigured position: 25.05,102.76,6407.0
2018-01-14 15:32:35 | [mlat][i]MLAT bandwidth reduction active, level 1
2018-01-14 15:32:35 | [mlat][i]Configuring UDP connection udp://52.76.75.15:19788
2018-01-14 15:32:35 | [mlat][i]Registering MLAT station
2018-01-14 15:32:36 | [mlat][i]Registering MLAT station: SUCCESS
2018-01-14 15:32:38 | [mlat][i]Received ADS-B time references AC:
2018-01-14 15:32:38 | [mlat][i] 780255
2018-01-14 15:32:38 | [mlat][i] 780613
2018-01-14 15:32:38 | [mlat][i] 7809F8
2018-01-14 15:32:38 | [mlat][i] 780BFD
2018-01-14 15:32:38 | [mlat][i] 780DB7
2018-01-14 15:32:38 | [mlat][i] 780F83
2018-01-14 15:32:38 | [mlat][i] 79A03F
2018-01-14 15:32:38 | [mlat][i]Pinging the server
2018-01-14 15:32:38 | [mlat][i]Stats 931297/931297
2018-01-14 15:32:41 | [feed][i]sent 10,0 AC
2018-01-14 15:32:46 | [feed][i]sent 10,0 AC
2018-01-14 15:32:52 | [feed][i]sent 9,0 AC
2018-01-14 15:32:57 | [mlat][i]Pinging the server
2018-01-14 15:32:57 | [mlat][i]Stats 931457/160
2018-01-14 15:32:57 | [feed][i]sent 7,0 AC

[Oblivian]

procargs="--net --net-http-port 8070"

Possibly Invalid, Dump1090 does not appear to be used for AVRTCP without DVBT - FR 'reader' software only

pi@raspberrypi:~ $ sudo service fr24feed start
pi@raspberrypi:~ $ pgrep -l dump
pi@raspberrypi:~ $


So quite different to diagnose as other thread where you said same issue, as his is using DVBT + Dump1090.

How many connections can flightfeeder have at one time? And is this amount being reached by the FR24feed restarting when no data is received at quiet times.. (this is what happens when too many pings reached)

Is it the same time at night/morning?

You will need to test by using telnet or other logging of the same 30002 output to see if fr24feed is being denied reconnection

[YsMilan]

procargs="--net --net-http-port 8070"

Possibly Invalid, Dump1090 does not appear to be used for AVRTCP without DVBT - FR 'reader' software only

pi@raspberrypi:~ $ sudo service fr24feed start
pi@raspberrypi:~ $ pgrep -l dump
pi@raspberrypi:~ $


So quite different to diagnose as other thread where you said same issue, as his is using DVBT + Dump1090.

How many connections can flightfeeder have at one time? And is this amount being reached by the FR24feed restarting when no data is received at quiet times.. (this is what happens when too many pings reached)

Is it the same time at night/morning?

You will need to test by using telnet or other logging of the same 30002 output to see if fr24feed is being denied reconnection

1.Now I've removed "--net --net-http-port 8070" to see what's going to happen.
2.I use only one connection for each flightfeeder.
3.The time of the mistake is random，I don't think it has anything to do with the number of planes.
4.Sorry,I don't know how to look at the 30002 output log.

[Oblivian]

You may only use one connection, but if the feeder is restarting quickly it may make a 2nd, 3rd connection and so on.

Tools like Virtual radar server, or 'telnet 192.168.1.15 30002' can monitor the output.

If the log continues to grow while not uploading, I don't know what can cause that. As it means its 'running' but not able to decode or connect to the data source all of a sudden

Under windows, if it crashes it closes totally so do not know how the processes work under linux.

[YsMilan]

I use telnet to monitor the port, waiting for the problem to happen.