As I have somethign else running onthe Pi that cannot bec changed from port 8080, I modified /etc/lighttpd/conf-enabled/89-dump1090-fa.conf
# $SERVER["socket"] == ":8080" {
$SERVER["socket"] == ":80" {
OS Rasbian Jessie (fully updated)
piaware version 3.6.3~bpo8+1
dump1090-fa version 3.6.3~bpo8+1
try ctrl-f5 in the browser.
if that doesn’t work show the output of the following command:
sudo journalctl -u lighttpd -n50 --no-pager
Also show the complete config file please.
Same issue appears in every browser across multiple computers (with slight changes to the wheel and progress bar), crtl+F5 has no effect,
pi@piaware:~ $ sudo journalctl -u lighttpd -n50 --no-pager
-- Logs begin at Thu 2019-01-03 19:54:11 UTC, end at Fri 2019-01-04 15:14:20 UTC. --
Jan 03 19:54:26 piaware systemd[1]: Starting Lighttpd Daemon...
Jan 03 19:54:27 piaware lighttpd[739]: Syntax OK
Jan 03 19:54:27 piaware systemd[1]: Started Lighttpd Daemon.
Jan 04 14:10:20 piaware systemd[1]: Stopping Lighttpd Daemon...
Jan 04 14:10:20 piaware systemd[1]: Starting Lighttpd Daemon...
Jan 04 14:10:20 piaware lighttpd[26022]: Syntax OK
Jan 04 14:10:20 piaware systemd[1]: Started Lighttpd Daemon.
Jan 04 14:15:56 piaware systemd[1]: Stopping Lighttpd Daemon...
Jan 04 14:15:56 piaware systemd[1]: Starting Lighttpd Daemon...
Jan 04 14:15:56 piaware lighttpd[26377]: Syntax OK
Jan 04 14:15:56 piaware systemd[1]: Started Lighttpd Daemon.
pi@piaware:~ $ cat /etc/lighttpd/conf-enabled/89-dump1090-fa.conf
# Allows access to the static files that provide the dump1090 map view,
# and also to the dynamically-generated json parts that contain aircraft
# data and are periodically written by the dump1090 daemon.
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/"
)
# Listen on port 8080 and serve the map there, too.
# $SERVER["socket"] == ":18080" {
$SERVER["socket"] == ":80" {
alias.url += (
"/data/" => "/run/dump1090-fa/",
"/" => "/usr/share/dump1090-fa/html/"
)
}
# Add CORS header
server.modules += ( "mod_setenv" )
$HTTP["url"] =~ "^/dump1090-fa/data/.*\.json$" {
setenv.add-response-header = ( "Access-Control-Allow-Origin" => "*" )
}
I’m quite sure that this used to work, but it’s been a while since I looked at the local web interface…
just in case this is required
pi@piaware:~ $ cat /etc/lighttpd/lighttpd.conf
server.modules = (
"mod_access",
"mod_alias",
"mod_compress",
"mod_redirect",
# "mod_rewrite",
)
server.document-root = "/var/www/html"
server.upload-dirs = ( "/var/cache/lighttpd/uploads" )
server.errorlog = "/var/log/lighttpd/error.log"
server.pid-file = "/var/run/lighttpd.pid"
server.username = "www-data"
server.groupname = "www-data"
server.port = 80
index-file.names = ( "index.php", "index.html", "index.lighttpd.html" )
url.access-deny = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
compress.cache-dir = "/var/cache/lighttpd/compress/"
compress.filetype = ( "application/javascript", "text/css", "text/html", "text/plain" )
# default listening port for IPv6 falls back to the IPv4 port
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.assign.pl"
include_shell "/usr/share/lighttpd/include-conf-enabled.pl"
Comment out
$SERVER["socket"] == ":80" {
}
around that alias.url stuff.
the default port is already 80 so i don’t know if that causes any problems.
Or just set it to 81 and see if you can reach it there then
You can also check if there are other configs enabled (probably not)
ls /etc/lighttpd/conf-enabled
I have also had what appears to be the same issue runing on 18088, so I’m fairly sure that it is not the port.
As the image shows, it is not that the web page completely fails to render, it starts, and displays a map (centered near venice in Italy), but does not get any further…
pi@piaware:~ $ ls -al /etc/lighttpd/conf-enabled
total 8
drwxr-xr-x 2 root root 4096 Jun 8 2018 .
drwxr-xr-x 4 root root 4096 Jun 8 2018 ..
lrwxrwxrwx 1 root root 47 Jun 8 2018 88-dump1090-fa-statcache.conf -> ../conf-available/88-dump1090-fa-statcache.conf
lrwxrwxrwx 1 root root 37 Jun 8 2018 89-dump1090-fa.conf -> ../conf-available/89-dump1090-fa.conf
I had the same problem i just don’t remember what the reason was 
Fiddled too much with it.
Anyway does
IP/
work as an URL or is it the same?
If you don’t want to access it with IP/ then you don’t even need the section you modified you can just comment it out completely.
/dump1090-fa should still work.
Is dump1090-fa even running?
sudo journalctl -u dump1090-fa -n50 --no-pager
can you access http://pi/dump1090-fa/data/stats.json ?
Look for errors in your browser’s javascript console. (F12 in Chrome, etc)
pi@piaware:~ $ sudo journalctl -u dump1090-fa -n50 --no-pager
-- Logs begin at Fri 2019-01-04 15:30:58 UTC, end at Fri 2019-01-04 16:28:23 UTC. --
Jan 04 16:26:16 piaware systemd[1]: dump1090-fa.service holdoff time over, scheduling restart.
Jan 04 16:26:16 piaware systemd[1]: Stopping dump1090 ADS-B receiver (FlightAware customization)...
Jan 04 16:26:16 piaware systemd[1]: Starting dump1090 ADS-B receiver (FlightAware customization)...
Jan 04 16:26:16 piaware systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
Jan 04 16:26:16 piaware dump1090-fa[4694]: Fri Jan 4 16:26:16 2019 UTC dump1090-fa 3.6.3~bpo8+1 starting up.
Jan 04 16:26:16 piaware dump1090-fa[4694]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
Jan 04 16:26:16 piaware dump1090-fa[4694]: usb_claim_interface error -6
Jan 04 16:26:16 piaware systemd[1]: dump1090-fa.service: main process exited, code=exited, status=1/FAILURE
Jan 04 16:26:16 piaware systemd[1]: Unit dump1090-fa.service entered failed state.
Jan 04 16:26:16 piaware dump1090-fa[4694]: rtlsdr: error opening the RTLSDR device: Device or resource busy
Jan 04 16:26:46 piaware systemd[1]: dump1090-fa.service holdoff time over, scheduling restart.
Jan 04 16:26:46 piaware systemd[1]: Stopping dump1090 ADS-B receiver (FlightAware customization)...
Jan 04 16:26:46 piaware systemd[1]: Starting dump1090 ADS-B receiver (FlightAware customization)...
Jan 04 16:26:46 piaware systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
Jan 04 16:26:46 piaware dump1090-fa[4757]: Fri Jan 4 16:26:46 2019 UTC dump1090-fa 3.6.3~bpo8+1 starting up.
Jan 04 16:26:46 piaware dump1090-fa[4757]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
Jan 04 16:26:46 piaware dump1090-fa[4757]: usb_claim_interface error -6
Jan 04 16:26:46 piaware dump1090-fa[4757]: rtlsdr: error opening the RTLSDR device: Device or resource busy
Jan 04 16:26:46 piaware systemd[1]: dump1090-fa.service: main process exited, code=exited, status=1/FAILURE
Jan 04 16:26:46 piaware systemd[1]: Unit dump1090-fa.service entered failed state.
Jan 04 16:27:16 piaware systemd[1]: dump1090-fa.service holdoff time over, scheduling restart.
Jan 04 16:27:16 piaware systemd[1]: Stopping dump1090 ADS-B receiver (FlightAware customization)...
Jan 04 16:27:16 piaware systemd[1]: Starting dump1090 ADS-B receiver (FlightAware customization)...
Jan 04 16:27:16 piaware systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
Jan 04 16:27:16 piaware dump1090-fa[4766]: Fri Jan 4 16:27:16 2019 UTC dump1090-fa 3.6.3~bpo8+1 starting up.
Jan 04 16:27:16 piaware dump1090-fa[4766]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
Jan 04 16:27:16 piaware dump1090-fa[4766]: usb_claim_interface error -6
Jan 04 16:27:16 piaware dump1090-fa[4766]: rtlsdr: error opening the RTLSDR device: Device or resource busy
Jan 04 16:27:16 piaware systemd[1]: dump1090-fa.service: main process exited, code=exited, status=1/FAILURE
Jan 04 16:27:16 piaware systemd[1]: Unit dump1090-fa.service entered failed state.
Jan 04 16:27:47 piaware systemd[1]: dump1090-fa.service holdoff time over, scheduling restart.
Jan 04 16:27:47 piaware systemd[1]: Stopping dump1090 ADS-B receiver (FlightAware customization)...
Jan 04 16:27:47 piaware systemd[1]: Starting dump1090 ADS-B receiver (FlightAware customization)...
Jan 04 16:27:47 piaware systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
Jan 04 16:27:47 piaware dump1090-fa[4773]: Fri Jan 4 16:27:47 2019 UTC dump1090-fa 3.6.3~bpo8+1 starting up.
Jan 04 16:27:47 piaware dump1090-fa[4773]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
Jan 04 16:27:47 piaware dump1090-fa[4773]: usb_claim_interface error -6
Jan 04 16:27:47 piaware dump1090-fa[4773]: rtlsdr: error opening the RTLSDR device: Device or resource busy
Jan 04 16:27:47 piaware systemd[1]: dump1090-fa.service: main process exited, code=exited, status=1/FAILURE
Jan 04 16:27:47 piaware systemd[1]: Unit dump1090-fa.service entered failed state.
Jan 04 16:28:17 piaware systemd[1]: dump1090-fa.service holdoff time over, scheduling restart.
Jan 04 16:28:17 piaware systemd[1]: Stopping dump1090 ADS-B receiver (FlightAware customization)...
Jan 04 16:28:17 piaware systemd[1]: Starting dump1090 ADS-B receiver (FlightAware customization)...
Jan 04 16:28:17 piaware systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
Jan 04 16:28:17 piaware dump1090-fa[4783]: Fri Jan 4 16:28:17 2019 UTC dump1090-fa 3.6.3~bpo8+1 starting up.
Jan 04 16:28:17 piaware dump1090-fa[4783]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
Jan 04 16:28:17 piaware dump1090-fa[4783]: usb_claim_interface error -6
Jan 04 16:28:17 piaware dump1090-fa[4783]: rtlsdr: error opening the RTLSDR device: Device or resource busy
Jan 04 16:28:17 piaware systemd[1]: dump1090-fa.service: main process exited, code=exited, status=1/FAILURE
Jan 04 16:28:17 piaware systemd[1]: Unit dump1090-fa.service entered failed state.
stats are being fed to flightaware…
javascript console shows 3 404’s
jquery-3.0.0.min.js:4 GET http://piaware.internaldomain.com:18088/status.json 404 (Not Found)
jquery-3.0.0.min.js:4 GET http://piaware.internaldomain.com:18088/dump1090-fa/data/receiver.json?_=1546619095579 404 (Not Found)
jquery-3.0.0.min.js:4 GET http://piaware.internaldomain.com:18088/dump1090-fa/upintheair.json 404 (Not Found)
dump1090-fa can’t access the dongle.
did you check if a restart fixes it?
otherwise you might need to blacklist some drivers which want to use the dongle for receiving DVB-T 
The 404s are the cause of the problem, the skyview frontend can’t fetch the files generated by dump1090-fa successfully. Those URLs don’t match up with the configuration you posted earlier, so it’s hard to speculate exactly what’s going wrong, but I’d start by checking that /run/dump1090-fa/receiver.json exists.
(edit: it does look like dump1090-fa isn’t running because it can’t access the dongle; I’m going to guess you’re trying to run two different dump1090s)
very red faced, probably from when this started off as a fr24 feed (before I found flightaware), dump1090 was running from an init.d script, and feeding flightaware and fr24
apart from the obvious parts of stopping the init.d script dump1090 and starting the systemd dump1090-fa, is there anything else I need to change to make the flightaware and fr24 feeders use the dump1090-fa ?
just uninstall dump1090.
if lighttpd mods / configs are enabled you can disable them.
Yes, this is essential, but dont use remove argument. Use purge argument.
change setting from “receiver=dvbt” to “beast-tcp” and host/port to 127.0.0.1:30005.
If you dont change this setting, fr24feed will again install dump1090
sudo apt-get purge dump1090
sudo dpkg --purge dump1090sudi dokg --purge dump1090-mutability from the paths, and the lack of output from dpkg -s dump1090, the original dump1090 had been been manually installed, so I removed the initscripts with update-rc.d -remove and removed the init file
fr24 had already been configured to use 127.0.0.1:3005. looking at the file dates (October 2016) I’m guessing that at some point I must have installed dump1090-fa, but never disabled the original which appears to be version 1.10.3010.14
thanks everyone for the assistance!