Can't get PIAware running

Not sure what’s happened, but went to check PIAware, and I now get the following error:

My Pi is still chucking out data to FlightAware and to my VRS installation - it’s just the PIAware web app that seems to be the issue.

I’ve re-booted the Pi, tried upgrading and restarting PIAware from the FlightAware Configure menu for the site in question.

Any thoughts or ideas?

Regards,

Mark

Mmh, not sure that is because it is working properly, but my feeder does not have a GPS - field…

Just checked, you have two sites, did you by any chance reimage a site without copying feeder id?

If that is the case, search for how-to on this forums and check posts by @abcd567

1 Like

Hi. Thanks for the reply. I did indeed do a re-image. I’ve now set the ID of my setup back to the original identifier and restarted but I still get the error shown above.

Any other suggestions gratefully received :blush:

Give following commands and post outputs

sudo systemctl status dump1090-fa -l

sudo systemctl status piaware -l

Not sure, maybe the ip changed, did you try to connect via the stats page or and old link? Does the sky view via the link on the status page?

IP is the same. The link on the FlightAware site to my SkyView shows me the error above.

Did you ssh to Pi and issue commands in my last post above? What are the outputs of these 2 commands?

1 Like

Here’s the results:

dump1090-fa.service - dump1090 ADS-B receiver (Fl Loaded: loaded (/lib/systemd/system/dump1090-fa. Active: active (running) since Wed 2018-08-22 17 Docs: PiAware - ADS-B and MLAT Receiver - FlightAware
Main PID: 433 (dump1090-fa)
CGroup: /system.slice/dump1090-fa.service
└─433 /usr/bin/dump1090-fa --net-bo-port
Aug 22 17:57:36 piaware systemd[1]: Started dump109Aug 22 17:57:36 piaware dump1090-fa[433]: Wed Aug 2Aug 22 17:57:37 piaware dump1090-fa[433]: rtlsdr: uAug 22 17:57:37 piaware dump1090-fa[433]: Found RafAug 22 17:57:37 piaware dump1090-fa[433]: rtlsdr: elines 1-13/13 (END)

piaware.service - FlightAware ADS-B uploader
Loaded: loaded (/lib/systemd/system/piaware.serv Active: active (running) since Wed 2018-08-22 20 Docs: PiAware - ADS-B and MLAT Receiver - FlightAware
Main PID: 6959 (piaware)
CGroup: /system.slice/piaware.service
├─6959 /usr/bin/piaware -p /run/piaware/ ├─6989 /usr/lib/piaware/helpers/faup1090 └─6998 /usr/lib/piaware/helpers/fa-mlat-
Aug 22 20:54:40 piaware piaware[6959]: 1756 msgs reAug 22 20:59:11 piaware piaware[6959]: mlat-client(Aug 22 20:59:11 piaware piaware[6959]: mlat-client(Aug 22 20:59:11 piaware piaware[6959]: mlat-client(Aug 22 20:59:11 piaware piaware[6959]: mlat-client(Aug 22 20:59:11 piaware piaware[6959]: mlat-client(Aug 22 20:59:11 piaware piaware[6959]: mlat-client(Aug 22 20:59:40 piaware piaware[6959]: 1916 msgs reAug 22 21:04:40 piaware piaware[6959]: 2099 msgs reAug 22 21:09:40 piaware piaware[6959]: 2275 msgs relines 1-20/20 (END)

I have recently also installed PiHole on my Pi which runs runs in port 80. Pretty sure I’ve viewed SkyView on 8080 since then so I don’t think that should be any conflict.

Cheers,

Mark

But the Go to map button works?

It might be the Pi hole thing, try search for pi hole here to see if other people had issues (change to lightpd?)

No, that throws the error “ [ERROR]: Unable to parse results from queryads.php : Unhandled error message (Invalid domain! )”

As edited above, I think I remember people having problems with Pihole and Piaware on the same RPi

E.g. Lighttpd broken

The status command’s outputs show that both the dump1090 and piaware are working ok.

Your graphs (see screenshot below) also show that your old station 16904, which was inactive since August 5, has now started to work, as the blue line at right most end has raisen up from zero to some positive value.

Now try this

  1. Press (Ctrl+Shift+Delete) keys simultaneously to clear browser cache

  2. After clearing browser cache, press (Ctrl+F5) keys to reload the browser.

.

I think this is a local network problem that you’re having - whatever queryads.php is, it’s not part of piaware.

Clear your browser cache and doublecheck that you’re using the right IP.

Thanks for all the help folks. Looks like it’s almost certainly PiHole causing a clash so looks like I’ll need to re-image again (and set my ID back to the current one - thanks for the tip :blush:).

Thanks again everyone. I should have twigged it was PiHole lol.

I’ll get another Pi for PiHole as I love the application.

1 Like

Yep, they’re a good bunch here, that’s for sure :smile:

1 Like

@psionmark So if you haven’t bought a second pi yet, there is a way to make this work:

After installing pihole:

Use an editor to open /etc/lighttpd/external.conf
You could use the following command:

sudo nano /etc/lighttpd/external.conf

Now copy and paste the following:

#this should go into /etc/lighttpd/external.conf

server.modules += (
"mod_alias"
)

# Listen on port 8080 and serve the map there, too.
$SERVER["socket"] == ":8080" {
  alias.url += (
  "/dump1090-fa/data/" => "/run/dump1090-fa/",
  "/dump1090-fa/" => "/usr/share/dump1090-fa/html/",
  "/data/" => "/run/dump1090-fa/",
  "/" => "/usr/share/dump1090-fa/html/"
  )
  url.redirect += (
    "^/dump1090-fa$" => "/dump1090-fa/"
  )
}

Press CTRL-o and ENTER to save
Press CTRL-x to exit

Restart lighttpd:

service lighttpd force-reload

Now it should be all running (theoretically)

This will host dump1090 webview on the port 8080, so you will have to use 192.168.1.123:8080 or whatever the rpi ip is to access it.

Edit: one test has been successful with a modification incorporated in this post (mod_alias was missing)

I am just trying this configuration, as I would like to reduce the number of connected devices and see if this can release a raspberry-pi. Currently I have implemented the file and checked that it is being used. The lighttpd service does not start with the current external.conf file I am using. The service shows:

● lighttpd.service - Lighttpd Daemon
Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2018-10-11 11:40:14 AEST; 4s ago
Process: 2385 ExecStart=/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS)
Process: 2544 ExecStartPre=/usr/sbin/lighttpd -tt -f /etc/lighttpd/lighttpd.conf (code=exited, status=255)
Main PID: 2385 (code=exited, status=0/SUCCESS)

Oct 11 11:40:13 raspberrypi systemd[1]: lighttpd.service: Unit entered failed state.
Oct 11 11:40:13 raspberrypi systemd[1]: lighttpd.service: Failed with result ‘exit-code’.
Oct 11 11:40:14 raspberrypi systemd[1]: lighttpd.service: Service hold-off time over, scheduling restart.
Oct 11 11:40:14 raspberrypi systemd[1]: Stopped Lighttpd Daemon.
Oct 11 11:40:14 raspberrypi systemd[1]: lighttpd.service: Start request repeated too quickly.
Oct 11 11:40:14 raspberrypi systemd[1]: Failed to start Lighttpd Daemon.
Oct 11 11:40:14 raspberrypi systemd[1]: lighttpd.service: Unit entered failed state.
Oct 11 11:40:14 raspberrypi systemd[1]: lighttpd.service: Failed with result ‘exit-code’.

journalctl -xe
Oct 11 11:40:13 raspberrypi systemd[1]: lighttpd.service: Failed with result ‘exit-code’.
Oct 11 11:40:14 raspberrypi systemd[1]: lighttpd.service: Service hold-off time over, scheduling restart.
Oct 11 11:40:14 raspberrypi systemd[1]: Stopped Lighttpd Daemon.
– Subject: Unit lighttpd.service has finished shutting down
– Defined-By: systemd
– Support: Debian -- User Support

– Unit lighttpd.service has finished shutting down.
Oct 11 11:40:14 raspberrypi systemd[1]: lighttpd.service: Start request repeated too quickly.
Oct 11 11:40:14 raspberrypi systemd[1]: Failed to start Lighttpd Daemon.
– Subject: Unit lighttpd.service has failed
– Defined-By: systemd
– Support: Debian -- User Support

– Unit lighttpd.service has failed.

– The result is failed.
Oct 11 11:40:14 raspberrypi systemd[1]: lighttpd.service: Unit entered failed state.
Oct 11 11:40:14 raspberrypi systemd[1]: lighttpd.service: Failed with result ‘exit-code’.
Oct 11 11:40:57 raspberrypi sudo[2566]: pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=/usr/bin/vi /etc/ligh
Oct 11 11:40:57 raspberrypi sudo[2566]: pam_unix(sudo:session): session opened for user root by (uid=0)
Oct 11 11:44:38 raspberrypi piaware[544]: 1 msgs recv’d from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware
Oct 11 11:45:04 raspberrypi sudo[2566]: pam_unix(sudo:session): session closed for user root

I would like to try and get this working and share the knowledge with the rest of the community if I can resolve the issue. Any thoughts would be appreciated.

Logs so far looked at

/var/log/lighttpd/error.log
2018-10-11 11:18:11: (server.c.1295) WARNING: unknown config-key: alias.url (ignored)
2018-10-11 11:18:40: (server.c.1828) server stopped by UID = 0 PID = 1
2018-10-11 11:18:50: (log.c.217) server started

/var/log/lighttpd/access.log
1539220871|192.168.27.14|GET /admin/api.php?summary HTTP/1.1|200|468
1539220873|192.168.27.14|GET /admin/api.php?summary HTTP/1.1|200|468
1539220875|192.168.27.14|GET /admin/api.php?summary HTTP/1.1|200|468

lighttpd -tp -f /etc/lighttpd/lighttpd.conf | less
Duplicate array-key ‘/dump1090-fa/data/’
2018-10-11 12:10:10: (configfile.c.1154) source: cat external.conf 2>/dev/null line: 9 pos: 15 parser failed somehow near here: (EOL)
2018-10-11 12:10:10: (configfile.c.1154) source: /etc/lighttpd/lighttpd.conf line: 76 pos: 1 parser failed somehow near here: (EOL)

I run PiAware and PiHole. But they are on separate Pi boxes. These things are so cheap it isn’t worth the trouble of trying to make them play nice with each other. They only use a couple of watts each too, so the power consumption is a non-issue. Both applications use port 80. So that’s a problem right there. PiHole will deliver an error acreen on port 80 for blocked sites. And it needs to stay there because port 80 is where every http request expects to find it. So you will have to move PiAware elsewhere. That assumes you fix the issue with piHole trying to reinstall lighttp somehow.

Operating on port 80 is not necessary for dump1090-fa.

@crabit

Add this to the beginning of the external.conf file please and report back with the journalctl -xe output:

server.modules += ( 
        "mod_access",
        "mod_alias",
        "mod_redirect",
        "mod_setenv" ,
)

Thank you for assisting on this “nice to have” fix. I had just started to understand the layout of the applications and like you say port 80 is not required for dump1090-fa. I had made progress and you have put the final piece together to get it working. The fix required is just to add the following into the external.conf file under /etc/lighttpd directory.

server.modules += (
“mod_alias”
)

All of the other lines exist in the lighttpd.conf file and journalctl -xe states that there are duplicate server modules trying to be loaded. As stated the external.conf file will not be overwritten if Pi-Hole updates as this only writes to the lighttpd.conf file.

I built the Pi with the base O/S then loaded Pi-Hole and then Pi-Aware. Modified the /etc/lightttpd/external.conf file and added as above. Pi-Aware now works on :8080 and Pi-Hole works on /admin.

I have also found that under the file /etc/lighttpd/conf-available/89-dump1090-fa.conf contains the default port number (8080) and can be changed to use a different port if wanted (tested using 8089).

I hope this helps other people that want to run both applications on one machine. Thanks for your help. Finally a few hours has paid off.

I’m not sure if there is a better place to put this fix but hopefully someone searching for it will come across Pi-Hole and Pi-Aware running together on the same machine.

3 Likes