Forget FR24 versions...
Pay no attention. It was between the 2 of us trying to work out how you likely installed the initial deployment of FR24. Because it isn't checking for new versions on the internet like it should.
Which makes me think other things may also be broken/skipped. The .sh script does a bit of setting up and background changes.
Bingo. Now you're starting to think down the same lines. Not sure if FA runs our of ram or disk
Anyway...
If you want to find a root (likely HW cause) We are still waiting on your results from local tests - WHILE PI SERVICES ARE OBSERVED TO BE CRASHED - DON'T TRY TO RESTART THEM
You need to find out why you can't:
SSH from a PC - FR24 doesn't touch this - like, at all! it is a core Linux component
Dump1090 updates fail - FR24 doesn't touch this either*
I've tried to clear it up with an image and listing before, but once more for luck...
If you have a Piaware image (quite clear you do). It installs:
Dump1090-fa
- Auto start on startup
- Installs lighttpd to serve web pages (ala local web view)
- Gets data from the USB stick. Saves to .json files, shows them on above page, sends same data to FA - FR24feed not linked
And just.. works. You can then add other apps to look at the existing decoded output without screwing with more.
A normal FR24feed install would then use the existing stuff. And all it would do is hook into the data output the same as everything else on :30005 and send it on it's way
However, it hasn't been designed fullproof - if you blind install fr24feed. And chose the wrong receiver type (DVBT) or mess with some settings not knowing consequences
It can:
Install a copy of dump1090-mutability instead
- Conflict with any other version present (that's a 2nd one that will fight)
Make it start ONLY when fr24feed is running
- Conflict
- Open duplicate ports already open (bind errors)
- Stop it restarting properly
Try open more of the same ports that Dump1090 has open if setting 'Raw out' and 'BS out' to ON - these should never be ON unless you know the specific circumstances allow.
But until you can rule out a fault and see why SSH stops for remote - which just shouldn't happen...
Pay no attention. It was between the 2 of us trying to work out how you likely installed the initial deployment of FR24. Because it isn't checking for new versions on the internet like it should.
Which makes me think other things may also be broken/skipped. The .sh script does a bit of setting up and background changes.
Originally posted by abcd567
View Post
Anyway...
If you want to find a root (likely HW cause) We are still waiting on your results from local tests - WHILE PI SERVICES ARE OBSERVED TO BE CRASHED - DON'T TRY TO RESTART THEM
You need to find out why you can't:
SSH from a PC - FR24 doesn't touch this - like, at all! it is a core Linux component
Dump1090 updates fail - FR24 doesn't touch this either*
I've tried to clear it up with an image and listing before, but once more for luck...
If you have a Piaware image (quite clear you do). It installs:
Dump1090-fa
- Auto start on startup
- Installs lighttpd to serve web pages (ala local web view)
- Gets data from the USB stick. Saves to .json files, shows them on above page, sends same data to FA - FR24feed not linked
And just.. works. You can then add other apps to look at the existing decoded output without screwing with more.
A normal FR24feed install would then use the existing stuff. And all it would do is hook into the data output the same as everything else on :30005 and send it on it's way
However, it hasn't been designed fullproof - if you blind install fr24feed. And chose the wrong receiver type (DVBT) or mess with some settings not knowing consequences
It can:
Install a copy of dump1090-mutability instead
- Conflict with any other version present (that's a 2nd one that will fight)
Make it start ONLY when fr24feed is running
- Conflict
- Open duplicate ports already open (bind errors)
- Stop it restarting properly
Try open more of the same ports that Dump1090 has open if setting 'Raw out' and 'BS out' to ON - these should never be ON unless you know the specific circumstances allow.
But until you can rule out a fault and see why SSH stops for remote - which just shouldn't happen...
Comment