Archived: Feed issues with 19-2

[abcd567]

@mgunther
Thanks. Your contribution are very valuable, as I have always experienced in past.
thumbs-up-3.jpg

[mgunther]

@loplo Give it a few minutes. The stats have to start building up again. Hourly graphs should appear first - at least they did for me.

[loplo]

@mgunther thanks. This fixed my dump1090 page, but the (adsbreceiver) stats are still down.

[ahdigital]

FYI
Just received email answer from FR24 support. A newer build is supposed to be deployed tomorrow.

Quoting fr24's email: "Sorry for the late reply. We had missed the emails.

This [the fr24 feed stopped] because of an update we released. Please leave them [the feeds] like this for now. We are working on a newer build that will hopefully fix all the issues. Currently aiming for a release tomorrow. Your feeds should get updated automatically.
--
Best Regards,
Flightradar24"


Gesendet von iPhone mit Tapatalk

[MrMac]

How do you temporarily disable the automatic updater?

https://forum.flightradar24.com/threads/11448-How-to-disable-fr24feed_updater-sh

/M

[mgunther]

Hi Oblivian,

Thanks to your previous two posts and other contributions I got my installation working again. I have dump1090-mutability v1.15~dev with a few modifications and performance monitoring.

Indeed, the file /etc/systemd/system/fr24feed.service was causing a few issues:

1) By doing '/bin/chown -R nobody:nogroup /run/dump1090-mutability' it prevented dump1090-mutability writing into this directory with two effects:
a) dump1090 map display was not updating
b) performance data were not collected

I removed the '/run/dump1090-mutability' from this line and I also issued the following command to reset the correct permissions for this directory:

~ $ sudo chown -R dump1090:nogroup /run/dump1090-mutability

2) The fr24feed process does not seem to work well when running as 'nobody' user. I observed 3 effects:
a) it was unable to resolve 'localhost' and connect to dump1090 on port 30005 (I fixed by specifying 127.0.0.1:30005)
b) it was unable to run NTP as seen in the log: '[time][e]Failed to synchronize time'
c) it was unable to connect to feed.flightradar24.com as seen in the log: '[e]Could not connect to feed.flightradar24.com, errno: 101'

I tried your suggestion to run it interactively (sudo fr24feed), and this worked. Therefore, for now I edited /etc/systemd/system/fr24feed.service again and specified the 'root' user. This is working for now. The file currently looks like this:

[Unit]
Description=Flightradar24 Decoder & Feeder
After=network-online.target

[Service]
Type=simple
Restart=always
LimitCORE=infinity
ExecStartPre=-/usr/lib/fr24/install_dump1090.sh
ExecStartPre=-/bin/mkdir -p /run/dump1090-mutability /var/log/fr24feed /run/fr24feed /var/log/lighttpd
ExecStartPre=-/bin/touch /dev/shm/decoder.txt
[B]ExecStartPre=-/bin/chown -R nobody:nogroup /var/log/fr24feed /run/fr24feed /dev/shm/decoder.txt[/B]
ExecStartPre=-/bin/chmod a+rwx /var/log/lighttpd
ExecStart=/usr/bin/fr24feed
User=root
Group=nogroup
PermissionsStartOnly=true

[Install]
WantedBy=multi-user.target

Feel free to edit/move/remove post as required.

[Oblivian]

Hi guys. I appreciate your efforts in trying to fix stuff. I had the same problem as many users (if not all of them).
I just run the script install_fr24_rpi.sh (dump1090-mutablity was OK). So far fr244feed service is running, dump1090-mutability looks happy and receiving planes.
The only problem is that I canīt connect fr24:

Linux/generic/static_arm/1.0.19-5
Updated: 10:51:53 GMT+0000 (GMT Standard Time)

FR24 Link: Disconnected (connection error)
FR24 Radar Code: N/A
Aircraft Tracked (ModeS & ADS-B): 22
Aircraft Uploaded: N/A
Receiver: dvbt, Connected
MLAT running: NO

I noticed a time sync problem when I look at the Status variables:

time_update_utc="1516618311"
time_update_utc_s="2018-01-22 10:51:51"
timing_last_result="failure"
timing_time_last_attempt="1516618311"

Could it be the cause of the connection failure of the fr24feed service?
This is getting a mess...
Cheers

Not alone

https://forum.flightradar24.com/threads/9132-Beta-test-new-Flightradar24-MLAT-software-for-Raspberry-Pi?p=100438&viewfull=1#post100438

[fr24-pad]

I would respectfully submit that the installation update process should be refactored and that the "fr24feed_updater.sh" update script should be abandoned. Debian is full of software infrastructure that supports installation and update dependencies. Running a "hidden" update script on it's own from from systemd (at fr24feed startup) and cron doesn't seem like a good idea. Especially when it changes file permissions and creates unsafe conditions on the server. Experienced Debian users have been able to unpick this mess and get things running again (without re-imaging, sorry but this is terrible advice) but many people have been left with a broken system and little idea how to fix it.

In summary - use the installation and update tools that Debian has put at your disposal and stop reinventing the wheel.

[elljay]

Keep up the good work, Oblivian & abcd567! I hope the guys at FR buy you a beer or three for helping sort out the chaos this upgrade's caused!

[abcd567]

I have been trying workarounds since last two days. It is a fluid situation, as fr24feed is being updated by Flightradar24 staff to overcome the crisis. As a result workarounds I found and posted for ver 19-2 are no more valid for newer ver 19-5.

I have found that easiest fix for those using Pi24 is to re-image, then run update script as follows:

cd /usr/lib/fr24
sudo ./fr24feed_updater.sh

[Oblivian]

Will try keep this updated..

Errors/What we (as un-advised volunteers and feeders) seem to find:

Changes to update daily script from Jan 9 (v19-2) removed Dump1090-MR leaving many feeders offline and needing Dump1090 installed again

New way to see whats broken from 19-2
- sudo fr24feed-status

Not running scripts with 'sudo'
- can change file permission, skip parts of the script and cause auto start/stop issues

If installing, unless you know how to do dump1090 manually and fix things after
- Wait for manual script to be re-engineered
- don't apt-get update/install it
- the only manual steps that seem to work (sometimes) http://forum.flightradar24.com/threa...6479#post66479

Dump1090 web-view AJAX/Data out of date error
- fix https://forum.flightradar24.com/thre...l=1#post100329

-Users reporting time sync/server when run as service.
- local lookup jessie connection issues likely
- investigating, but running as std output works. (Sudo fr24feed stop, sudo fr24feed)
- Ping permission needs adjustment (added to later install script sudo chmod 4755 /bin/ping)

FR24feed Not auto-starting on reboot
- Not sure why/not enough info provided to pinpoint cause or fix
- poss owner of run service string (adjusted in later script)

Usual "usb_claim_interface error -6" error
- USB in use - dump1090 may need to be 'killed', or purged and installed again.

bash: /usr/lib/fr24/dump1090: No such file or directory
- virtual device fr24feed looks for 'Dump1090' linking failed (ln -s /usr/bin/dump1090-mutability /usr/lib/fr24/dump1090)
- Dump1090 missing

Dump1090 appears to be run ON-DEMAND as fr24feed is started (not service)
- Expect issues if its already going
- Will not allow fulltime/100% AVRTCP connection type if true

False Detection of existing Dump190 may skip needed file/setup changes

'Feeder offline'
- probably similar to above. It'll be Dump1090 not working when feeder is - always been around

'DVBT' / USB is main config with issues as Dump190-MR has been removed and -Mutability added
- Issues during dump1090 deployment experienced

New additional apps installed/needed
- librtlsdr0, libusb-1.0-0, dirmngr (fixes the old stretch install issue), lighttpd (for the web server) wget (to download dump1090)

Installer script doesn't kill Dump1090 possibly before installing a new one

Cron job for updating ap can undo-changes - can disable by:
sudo rm /etc/cron.d/fr24feed_updater

Force update to latest via:
sudo /usr/lib/fr24/fr24feed_updater.sh

Long way around while awaiting fix,
Purging related apps may have some success for those with patience and time to kill

https://forum.flightradar24.com/threads/11589-dump1090-issues-in-latest-feeder-package?p=100095&viewfull=1#post100095

Associated files

pi@raspberrypi:~ $ dpkg-query -L fr24feed
/etc/udev/rules.d/rtl-sdr.rules
/etc/systemd/system/fr24feed.service
/etc/cron.d/fr24feed_updater
/etc/fr24feed.ini
/usr/bin/fr24feed-status
/usr/bin/fr24feed
/usr/lib/fr24
/usr/lib/fr24/public_html
/usr/lib/fr24/public_html/coolclock
/usr/lib/fr24/public_html/coolclock/excanvas.js
/usr/lib/fr24/public_html/coolclock/coolclock.js
/usr/lib/fr24/public_html/coolclock/moreskins.js
/usr/lib/fr24/public_html/options.js
/usr/lib/fr24/public_html/gmap.html
/usr/lib/fr24/public_html/config.js
/usr/lib/fr24/public_html/script.js
/usr/lib/fr24/public_html/style.css
/usr/lib/fr24/public_html/planeObject.js
/usr/lib/fr24/public_html/extension.js
/usr/lib/fr24/fr24feed_updater.sh
/usr/lib/fr24/install_dump1090.sh

As for getting a little short at people/closing threads.

Basically anyone with DVBT chosen has been affected and is looking for quick answers that just aren't easy to give. Trying to give it and share of findings/fixes. Starting new threads because it doesn't quite seem related (when it really is.. ) prevents this crowd-help going.

And there's a lot of hours being put in to try and help ya'll with what is at our home-test-setup disposal

Keep in mind there is an official method of contacting support - email. Forums are actually secondary to this but doing our best. But expect delays

Frustration level is high [emoji14]

[abcd567]

How I Configured Pi24 To Run Piaware Data feeder + Display Flightaware MLAT Feed Back on Map

1. Installed Piaware data feeder on Pi24 as per Step-2 on Flightaware page https://flightaware.com/adsb/piaware/install
2. edited file /etc/fr24feed.ini and added process arguments line as below

sudo nano /etc/fr24feed.ini

receiver="dvbt"
fr24key="xxxxxxxxxxxxxxxxx"
bs="no"
raw="no"
logmode="0"
[COLOR="#FF0000"]procargs="--net --net-bi-port 30104"[/COLOR]
windowmode="0"
mpx="no"
mlat="yes"
mlat-without-gps="yes"

--net allows Piaware to get data of DVB-T in beast:30005 (dump1090-mut's default setting)
--net-bi-port 30104 allows Piaware to feed Flightaware MLAT data to dump1090-mutability so that dump1090-mut can display MLAT planes on Map. Please note that dump1090-mutability does NOT mix MLAT feedback from Flightaware with the data from DVB-T, and does not feed it to any other site. Dump1090-mut keeps the MLAT feedback segregated, and uses it ONLY for dispalying MLAT planes on your local Map

FR24 ProcArgs for Piaware ver 19-5.png

[abcd567]

Cant be sure but I have a feeling the fr24feed.ini has not only had permissions changed but possibly changed location in an attempt to force a fresh reconfigure. Which seems to break pre-existing settings...

No, the permissions and location of fr24feed.ini are retained. After upgrade, I could edit config from Web Browser, as well as directly in by sudo nano /etc/fr24feed.ini through SSH console.
NOTE: Should use sudo when running scripts for "auto-upgrade", else will get permission denied on some of the steps during execution of script.

Pi24 Upgrade ver 1.0.18-9 >> ver 1.0.19-5

[color=#00AA00]cd /usr/lib/fr24[/color]
[color=#00AA00][B]sudo[/B] ./fr24feed_updater.sh[/color]
...........
...........
Installed version: 1.0.18-9
Latest available: 1.0.19-5
Upgrading fr24feed...
Waiting for fr24feed to stop completely...
................
................
[COLOR="#FF0000"]Configuration file '/etc/fr24feed.ini'[/COLOR]
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
[COLOR="#FF0000"]*** fr24feed.ini (Y/I/N/O/D/Z) [default=N] ? [B]N[/B][/COLOR]

................
You don't seem to have any dump1090 installed. On the fr24feed start it will automatically install dump1090-mutability.
Created symlink from /etc/systemd/system/multi-user.target.wants/fr24feed.service to /etc/systemd/system/fr24feed.service.

In upgrade on one of my PI24, something got broken during installation of dump1090-mutability, and it did not get installed.
I fixed it by this method

[color=#00AA00][B]sudo[/B] dpkg --configure -a[/color]

[color=#00AA00]cd /usr/lib/fr24[/color]
[color=#00AA00]sudo ./install_dump1090.sh[/color]
.................
.................
Run /etc/init.d/lighttpd force-reload to enable changes
dump1090-mutability is installed. You can always override it in /etc/fr24feed.ini with any other supported driver.
Web server (aircraft map) at http://YOUR_DEVICE_IP/dump1090 is enabled by default.

PI24 ver 1.0.19-5

STATUS PAGE	SETTINGS PAGE	MAP
FR24 status ver 19-5.png	FR24 settings ver 19-5.png	FR24 map ver 19-5.png

[fr24-pad]

"if grep -q dvbt /etc/fr24feed.ini && [ ! -e /usr/lib/fr24/dump1090 ] ; then"

What if "dvbt" is present in the fr24feed.ini file but it is commented out? A better solution might be to evaluate the file and check the value of $receiver.

[fr24-pad]

/var/run data "missing" after fr24feed 1.0.19-5 update

After the recent issues with fr24feed updates (missing dump1090) I moved to a stand-alone version of dump1090-mutability and configured fr24feed to use it via the "avr-tcp" mechanism. The most recent update of fr24feed is now interfering with dump1090-mutability's data files in /run/dump1090-mutability. The behaviour can be reproduced as follows:

1. stop both daemons (sudo service fr24feed stop; sudo service dump1090-mutability stop)
2. remove /run data files (sudo rm -fr /run/fr24feed /run/dump1090-mutability)
3. start dump1090-mutability (sudo service dump1090-mutability start)
4. ls -lar /run/dump1090-mutability
This indicates that the files belong to the dump1090 user
5. start fr24feed (sudo service fr24feed start)
4. ls -lar /run/dump1090-mutability
This indicates that the files' permissions have been changed (to the nobody user, the one that runs fr24feed). After this the dump1090 process can no longer write to the /run/dump1090 directory and this breaks the web interface and anything that might be using those files.

A quick work-around is to change the dump1090-mutability data file location in /etc/default/dump1090-mutability. If you are using lighttpd to serve dump1090-mutability's web interface you will also need to change the data dile location in /etc/lighttpd/conf-available/89-dump1090.conf.

Clearly, some more rigorous unit and regression testing needs to be used by whomever is creating the fr24feed releases. Using an upgrade script outside of Debian's package management system does not seem to be helping matters either.