I’ve installed the latest lighttpd version but still get same error when reinstalling tar 1090
Yeah that’s not it.
# Listen on port 8080 and serve the map there, too.
$SERVER["socket"] == ":8080" {
alias.url += (
"/data/" => "/run/dump1090-fa/",
"/" => "/usr/share/dump1090-fa/html/"
)
# Listen on port 8080 and serve the map there, too.
$SERVER["socket"] == ":8080" {
alias.url += (
"/data/" => "/run/dump1090-fa/",
"/data-978/" => "/run/skyaware978/",
"/" => "/usr/share/skyaware/html/"
)
}
the dump1090-fa lighttpd config file hasn’t been updated.
dump1090-fa --version
Can you give the output of the above?
This will temporarily solve the issue not sure why it’s not updating that lighttpd config file.
sudo lighty-disable-mod dump1090-fa
sudo systemctl restart lighttpd
Re-enabling once the issue is fixed:
sudo lighty-enable-mod dump1090-fa
sudo systemctl restart lighttpd
Alternatively you could also disable the skyaware lighttpd mod.
Or remove the :8080 section from either of the config files.
Did support for Bing maps get disabled?
I have my key in /usr/share/dump1090-fa/html/config.js
but it doesn’t seem to work. I have restarted my device.
I was having the same issue after upgrading to 5.0. After executing these two commands and it is working now
sudo lighty-disable-mod dump1090-fa
sudo systemctl restart lighttpd
I did get this message after running “sudo lighty-disable-mod dump1090-fa”. I don’t know if this is probably or not:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_ADDRESS = “en_US.UTF-8”,
LC_NAME = “en_US.UTF-8”,
LC_MONETARY = “en_US.UTF-8”,
LC_PAPER = “en_US.UTF-8”,
LC_IDENTIFICATION = “en_US.UTF-8”,
LC_TELEPHONE = “en_US.UTF-8”,
LC_MEASUREMENT = “en_US.UTF-8”,
LC_TIME = “en_US.UTF-8”,
LC_NUMERIC = “en_US.UTF-8”,
LANG = “en_GB.UTF-8”
are supported and installed on your system.
perl: warning: Falling back to a fallback locale (“en_GB.UTF-8”).
| dump1090 ModeS Receiver dump1090-fa 5.0 |
| build options: ENABLE_RTLSDR ENABLE_BLADERF ENABLE_HACKRF ENABLE_LIMESDR |
|---|
| detected runtime CPU features: ARMv7+NEON+VFPv4 |
| selected DSP implementations: |
magnitude_uc8 neon_vrsqrte_armv7a_neon_vfpv4
magnitude_uc8_aligned neon_vrsqrte_armv7a_neon_vfpv4_aligned
magnitude_power_uc8 neon_vrsqrte_armv7a_neon_vfpv4
magnitude_power_uc8_aligned neon_vrsqrte_armv7a_neon_vfpv4_aligned
magnitude_sc16 neon_vrsqrte_armv7a_neon_vfpv4
magnitude_sc16_aligned neon_vrsqrte_armv7a_neon_vfpv4_aligned
magnitude_sc16q11 neon_vrsqrte_armv7a_neon_vfpv4
magnitude_sc16q11_aligned neon_vrsqrte_armv7a_neon_vfpv4_aligned
mean_power_u16 u32_armv7a_neon_vfpv4
mean_power_u16_aligned u32_armv7a_neon_vfpv4_aligned
This has got both tar 1090 and Skyaware working for me, however, once I re-enable it stops again
1 Like
It looks like it depends on how the upgrade took place. If you are manually running apt upgrade, apt will ask you if you want to upgrade the updated files for 89-dump1090-fa.conf
I have both files as I said “no” and have it and 89-dump1090-fa.conf.dpkg-dist
The Diff is /data and / was deleted
If you don’t get the updated files it blows up. My correction and I ran update via web interface of flightware.com
cd /etc/lighttpd/conf-available
sudo cp 89-dump1090-fa.conf 89-dump1090-fa.conf.bak
sudo cp 89-dump1090-fa.conf.dpkg-dist 89-dump1090-fa.conf
sudo systemctl restart lighttpd
Your mileage may vary
my 89-dump1090-fa.conf. Comments mostly removed
alias.url += (
"/dump1090-fa/data/" => "/run/dump1090-fa/",
"/dump1090-fa/" => "/usr/share/dump1090-fa/html/"
)
# redirect the slash-less URL
url.redirect += (
"^/dump1090-fa$" => "/dump1090-fa/"
)
# Add CORS header
#server.modules += ( "mod_setenv" )
$HTTP["url"] =~ "^/dump1090-fa/data/.*\.json$" {
setenv.set-response-header = ( "Access-Control-Allow-Origin" => "*" )
}
You may need to add it to /usr/share/skyaware/html/config.js until we remove dump1090-fa map
1 Like
Yeah i suppose that could be related to tar1090 after all as tar1090 will comment out the mod_setenv files so tar1090 can work correctly.
(adding mod_setenv more than once in dump1090-fa / skyaware978 meant that mod_setenv would not work correctly that’s why i had to add my workaround)
Now if the file was changed … it will ask for confirmation in updating the file or not update it if the upgrade is unattended and no overwrite of config files is specified.
tar1090 removing mod_setenv will mean the file was changed.
So … purging dump1090-fa and reinstalling it would probably work but is ugly as /etc/default/dump1090-fa is lost.
Easiest solution will probably just downloading the new version.
sudo wget -O /etc/lighttpd/conf-available/89-dump1090-fa.conf https://raw.githubusercontent.com/flightaware/dump1090/master/debian/lighttpd/89-dump1090-fa.conf
sudo systemctl restart lighttpd
This will mean mod_setenv will get loaded twice again which will be corrected for tar1090 once the tar1090 install script is re-run. Anyhow it just causes issues with history loading the interface itself will continue working.
@obj @eric1tran
The best solution would probably be using dedicated config file for mod_setenv and stat-cache.
Just needs a common naming scheme.
On new lighttpd installs i’ve even seen modules provided by lighttpd i believe that pretty much do the same.
As mentioned previously i’m currently using:
07-mod_alias.conf
07-mod_setenv.conf
47-stat-cache.conf
Apparently in newer lighttpd version there is this module available from the lighttpd install on debian (unstable):
05-setenv.conf
So i’d be more than fine to change to using that naming convention.
05-alias.conf
05-setenv.conf
05-stat-cache.conf
That could alleviate such issues.
All packages that agree to the convention would just create that file with the obvious content and then activate the module if they need that functionality.
Yeah that seems like a good plan going forward, i’ll change tar1090 to use those modules.
Well that 05-setenv.conf shipped by default has some other stuff in there which is commented out by default though.
There is always chance for breakage and it would seem logical for modules named like that to ONLY add that server module and do nothing else.
In the end … even agreeing just on this forum on some sort of convention for this is probably gonna be a win there is always gonna be potential for breakage as long as lighttpd doesn’t fix their module loading.
As such … you choose 07 or 05 with mod_ or without i’ll just follow.
dpkg will leave the “new” version somewhere obvious (from memory it’s at <base path>.dpkg-new) so you could just copy that over and re-apply your changes.
Yeah, I agree; let’s look at this for 6.0.
That said … trying to do a nice modular config that integrates with whatever else on the system seemed like a good idea at the time, but it’s getting really painful to maintain. I’m leaning more and more towards running a standalone webserver on 8080 (or whatever port) only, with a selfcontained config specifically to serve the map and nothing else.
Good afternoon,
trying to update with
But for some reason piaware stays red and says 4.0 is running.
What id I do wrong?
Thanks for the help and advice
Can someone with the issue share the following:
ls -a /etc/lighttpd/conf-available | grep dump
pi@piaware:~ $ ls -a /etc/lighttpd/conf-available | grep dump
88-dump1090-fa-statcache.conf
89-dump1090-fa.conf
89-dump1090-fa.conf.dpkg-dist
edit: this is after running the disable-mod command
It may have just run into issue the first time. I upgraded it again and it looks ok now.
@eric1tran
Did as you suggested. But now it seems my Mlat is not running.
Did run dump1090-fa --version
So … this will fix the issue and isn’t as ugly as loading the config file from the web:
sudo mv /etc/lighttpd/conf-available/89-dump1090-fa.conf.dpkg-dist /etc/lighttpd/conf-available/89-dump1090-fa.conf
sudo systemctl restart lighttpd
I’ve built something into tar1090 also … it checks for the duplicate error and if applicable will overwrite the 89-dump1090-fa conf with with .dpkg-dist version if that’s available.
So people who just rerun the tar1090 installer after updating dump1090-fa … won’t have to run the above command.
Maybe that will prevent some questions. I suppose most people might find this thread and just use the two lines given above.
2 Likes
Not sure if this is related to everything else being discussed, but I’m also seeing much higher ADS-B CPU utilization and slightly higher overall CPU usage after upgrading to 5.0.
EDIT: just noticed that this is expected due to the higher message rate