A few nights ago, we had a power outage at my house overnight. The next morning as I was getting all my network gear back up and running and checking on my RPi I noticed that it was feeding data fine to everything but FR24. I did a few things, but could never get it started. I downloaded the SD card image from ADSB Receiver (too bad they aren’t active anymore) and decided to grab the dump1090-fa image this time where previously I had used mutability. When I booted up I could use the Dump1090 PA page and it worked fine. It wasn’t feeding data to FA yet but a quick mod of the piaware config and it was back working. I went ahead and added my PlaneFinder and FR24 feed to the mix and in the process (and I think it even said that) my dump1090 FA page stopped working. I am assuming because FR24 loads Dump1090 Mutability. Is there a way to fix this so I can access Dump1090 FA? At this point I don’t have access to the Mutability page either, but I am finding the PlaneFinder client isn’t too shabby!
After facing FR24 update crash, I have done following, and the feeds are working successfully
-
Downloaded latest Piaware SD card image 3.5.3 from this page, and burned it to microSD card:
PiAware - build your own ADS-B ground station for integration with FlightAware - FlightAware -
After boot and setting feeder-id in piaware-config, gave following command to install latest Flightradar Feeder (ver 1.0.19-5)
sudo bash -c "$(wget -O - http://repo.feed.flightradar24.com/install_fr24_rpi.sh)"
.
-
After completing Flightradar24 sign-up process (giving your email and feeder key, latitude, longitude, etc), go to browser and type following:
ip-of-pi:8754/settings.html
and choose
Receiver: ModeS Beast
Host/Port: 127.0.0.1:30005IMPORTANT: After entering settings, click first the “Save” button, then “Resrart” button. Both these buttons are at bottom-right of settings page.
When you did this, did it get the SkyView working again?
I think what I am going to do is backup what i have on the card right now, and switch to the PiAware image and then add FR24, PF and ADSB Exchange individually afterwards.
Q[quote=“cpohlad, post:3, topic:30667, full:true”]
When you did this, did it get the SkyView working again?
[/quote]
- I did it yesterday
- Yes, SkyView is working.
I did it in following sequence:
-
Formatted microSD card
-
Burned Piaware 3.5.3 image to microSD card
-
Added my Flightaware feeder id:
sudo piaware-config feeder-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx sudo systemctl restart piawareWhere xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx is
Unique-identifierI copied from my stats page. You can copy it from your stats page
Chris Pohlad-Thomas ADS-B Feeder Statistics - FlightAware. -
Installed FR24 feeder by bash script
sudo bash -c "$(wget -O - http://repo.feed.flightradar24.com/install_fr24_rpi.sh)"
- Installed Planefinder feeder by wget and dpkg commands below:
wget http://client.planefinder.net/pfclient_3.7.40_armhf.deb
sudo dpkg -i pfclient_3.7.40_armhf.deb
- Installed Radarbox24 feeder by bash script
sudo bash -c "$(wget -O - http://apt.rb24.com/inst_rbfeeder.sh)"
-
Have not yet installed Adsbexchange feeder. Will try to install it by manual method given here:
https://discussions.flightaware.com/t/bake-a-pi/19886/5
Scroll down to item (3) INSTALLATION OF ADSBEXCHANGE DATA FEEDER
FYI
Luckily unlike previous FR24 upgrade (v 1.0.19-2), the latest upgrade (ver 1.0.19-5), does NOT interfere with dump1090-fa.
However it does interfere with pre-installed dump1090-mutability. The reason is that now instead of its integral dump1090 Malcolm Robb, FR24 feeder installs dump1090-mutability ver 1.14 (package install). It also modifies permissions and ownerships of dump1090-mutability files & folders through its file /etc/systemd/system/fr24feed.service.
This is ok if there was no dump1090-mutability pre-installed, and suits the dump1090-mutability 1.14 installed by FR24 feeder. It however severely affects functioning of an existing dump1090-mutability ver 1.14 and ver 1.15~dev
@cpohlad: Try this fix before re-imaging:
- Open file frfeed.service for editing
sudo nano /etc/systemd/system/fr24feed.service
- In following line, change nobody:nogroup to dump1090:nogroup
ExecStartPre=-/bin/chown -R nobody:nogroup /run/dump1090-mutability /var/log/fr24feed /run/fr24feed /dev/shm/decoder.txt
- Save file (Ctrl+o) and close file (Ctrl+x)
Reboot
sudo reboot
.I actually already re-imaged and am glad I did. I think I got everything
the way I wanted it!
Great!
Thank you for your help! I’ve read a lot of the stuff you’ve posted here
and you are a wealth of knowledge.
UPDATE
Try this solution by @mgunther (Marcus):
sudo nano /etc/systemd/system/fr24feed.service
In this file, edit the line
User=nobody
to
User=root
For details, please see this post:
https://forum.flightradar24.com/threads/11589-Feed-issues-Dump1090-problem-with-latest-package?p=100578&viewfull=1#post100578
@abcd567 This User change affects the fr24feed service only. For me, the fr24feed does not run properly as ‘nobody’ user. That’s why I changed this setting and now the fr24feed runs as ‘root’ user.
You can see this by running ‘top’ from command line: it shows all running processes and which user a process is running as. Press ‘q’ to quit the ‘top’ utility.
@mgunther
Following is very strange:
Yesterday (or maybe day before yesterday), I re-imaged a microSD card with Raspbian Stretch Lite, installed dump1090-mutability v1.15~dev, and installed fr24feed 1.0.19-5 (current at that time).
Neither dump-mut map nor fr24feed worked, till I carried out the fix as proposed by you in file fr24feed.service. After applying the fix, everything started working smoothly.
Today morning I upgraded fr24feed from ver 1.0.19-5 to ver 1.0.19-6. It all went smooth and everything working OK after upgrade.
When I checked the file fr24feed.service , I found that the copy modified by me when applying fix in version 1.0.19-5, has been replaced during upgrade by an unmodified version, like it was before applying the fix.
I thought the new permissions/ownership is not yet implemented, and fr24feed and dump1090-mut will again crash when these are implemented. I then rebooted the Pi to make sure new ownership/permission settings are implemented. I was surprised to see that even after reboot, everything is working ok without the fix.
P.S.
I will re-image with Raspbian Stretch Lite tonight, the install dump1090-mutability ver 1.15~dev, and fr24feed ver 1.0.19-6 directly and see if it works with or without fix to fr24feed.service file.
@abcd567 I’m fairly sure the dump190-mutability directory permission issue was fixed in fr24feed version 1.0.19-6, i.e. the feeder stopped messing with it. So what you saw is expected behaviour in my opinion.
Some people that were affected may still have to undo the damage that was done:
~ $ sudo chown -R dump1090:nogroup /run/dump1090-mutability
After completing Flightradar24 sign-up process (giving your email and feeder key, latitude, longitude, etc), go to browser and type following:
ip-of-pi:8754/settings.html
and choose
Receiver: ModeS Beast
Host/Port: 127.0.0.1:30005
Changing the FR24Feed settings from AVR (TCP) to ModeS Beast (TCP) caused a delay for my FlightAware statistics.
The “Feeder Check-In:” was showing 2-3 minutes (instead of ‘a few seconds ago’) and the “FLIGHTS WITH POSITIONS FROM THIS FEEDER ON FLIGHTAWARE.COM WITHIN THE LAST HOUR” disappeared. I rebooted and waited for a while, it did not help.
After I changed the FR24Feed settings back to AVR (TCP) and rebooted my Pi, FlightAware was running fine again.