piaware-config appears to leave unset /var/cache/piaware/location.env

[fche]

With 3.8.0~bpo9+1 (installed semiautomatically over time from an 3.5ish initial installation), While the mlat* programs do know our location, the dump1080-fa program doesn't, so the web map lacks the proper location / range-rings, apparently because /var/cache/piaware/location.env was not created with the correct PIAWARE_LAT/_LON variable settings.

ISTM there should be one central place where location coordinates are stored on piaware, and it should include the dump1080-fa AND the mlat daemons as readers.

[mutability]

piaware-config does not write this file; this file is written by piaware itself based on the site location you have configured on the FlightAware website, obtained when piaware connects to the FA servers. Do you have that configured?

The location is obtained by mlat on the server side directly, it is not passed to fa-mlat-client on the client side. The location is passed to faup1090 (for e.g. surface position decoding) but that uses the same location data that is also written out by piaware (and piaware handles restarting faup1090 when it changes), so I can't see a scenario where the cached environment data would be out of sync with how faup1090 is running.

[fche]

Hi! When I first noticed the receiver-position-unset issue (on the piaware web server), the first thing I tried was resetting the location on the flightaware adsb web site. That was accepted, but did not result in the location data being written to that location.env file, because the webapp could still not see it. This was several attempts over the past year.

[mutability]

What FlightAware ADS-B site are you seeing the problems with?

[fche]

this is site 23867 (the problem is now fixed, by manual creation of that file)

[mutability]

Was the issue that the file did not exist at all, or that it had stale contents?

[fche]

did not exist (only became aware of it by reverse engineering some of the piaware startup scripts)

maybe this data should also go into /boot/piaware.txt or somesuch

[mutability]

Your piaware is reporting at least one odd thing, which is that /var/cache/piaware/feeder_id is not writable by the user that piaware is running as (I can't tell from what I see on the server side whether this is because the directory is not writable, or because the file itself is not writable).

If /var/cache/piaware is not writable by the piaware user, then that would explain why piaware failed to create the location file, too; I suspect you just have a directory permission issue here.

What does ls -ld /var/cache/piaware look like?

[fche]

root@piaware:/var/cache/piaware# ls -al
total 16
drwxr-xr-x  2  495 root 4096 Feb  4 03:20 .
drwxr-xr-x 11 root root 4096 Feb 19  2019 ..
-rw-r--r--  1 root root   37 Feb 19  2019 feeder_id
-rw-r--r--  1 root root   43 Feb  4 03:21 location.env

good catch, wonder how the heck that happened

[mutability]

Yeah, the ownership there should be piaware:root. I'm not aware of anything on the piaware side that could cause that (that directory is created once on package install with the right permissions if it doesn't already exist, and left untouched otherwise), so I guess it was just a stray chown at some point.

I'd expect to see a complaint in /var/log/piaware.log during startup about this (just after login): https://github.com/flightaware/piaware/blob/master/programs/piaware/helpers.tcl#L332

[fche]

right again

/var/log/piaware.log.2:Jan 20 17:17:25 piaware piaware[394]: got 'couldn't open "/var/cache/piaware/location.new": permission denied' trying to update location files
/var/log/piaware.log.2:Jan 20 17:17:26 piaware piaware[394]: Failed to update feeder ID file at /var/cache/piaware/feeder_id: couldn't open "/var/cache/piaware/feeder_id.new": permission denied

[fche]

closing this issue as it seems to have been some weird local corruption (sdcard originated?) rather than a software bug