I came upon your code, (thanks btw for giving me new ways to use travis ;) ).

But thats not the point, I built the PiAware image and the mlat client keeps getting permission denied.

The one thing I changed was to version 3.6.3 of PiAware, so not sure what has changed since 3.5.3.

The ADSB-Exchange one is fine. I have been able to diagnose down to the Debian image and Python versioning as the issue.

I ended up just using there Debian builder but really like the freedom of your build to control the code.

Virtual Radar Server is not displaying aircraft silhouettes, flags or routes - despite the aircraft transmitting valid ICAO and callsign.

Merge GPS logic
https://github.com/bradsjm/docker-adsb/blob/fe0178a004d88dd2f4997db97527941576054f35/flightaware/piaware-runner.sh#L37-L40

the dump1090 logs are too verbose and fill the hosts disk quickly.

• The logs should be less verbose
• The logs should self truncate so not to disable the host

Raspberry Pi 2B / 1GB RAM / 4GB disk

My FA container has been dying after several hours with an error code of 137. That's pointing to an out of memory condition. But it restarts fine when I start it by hand. So I wanted to know why the docker-compose was not restarting the image.

It seems you are using the docker stack version of restart_policy in the yml but the docker stack restart policy requires "any" not "always". So I switched always to any. Then the startup failed due to no compatible nodes found. There's an issue with Raspberry Pis reporting different platforms between armhf, armv7, arm, etc. So to get it to try to start, I now run

docker stack up -c docker-compose.yml adbs --resolve-image=never

Then I run "watch docker stack ps adsb" to keep an eye on the stack. The containers reach a "preparing" state but never reach "running". I'm trying to figure out why. (Update: they eventually started after 15-20 minutes)

Also, in your dump1090 config, you have a constraints block that limits dump1090 to only run on a host named "shed". I'm guessing you run your dump1090 literally in a shed outside and that's why you only want to run it there. That doesn't work for the rest of us! I deleted the constraint block and dump1090 is now willing to start on my Pi.

Right now, I can get dump1090, fa, and fr24 to reach a preparing state in docker stack. The images show up in "docker images ls" but nothing shows up in "docker ps -as". I'll keep working on it. For this new issue, though, the restart_policy needs to be "any" not "always" to be compatible with docker stack. "Always" is for use with docker-container but the rest of the restart_policy block is not compatible with docker-container as written. Hence my containers are dying with error 137 and not restarting.

Update: Again, they eventually started after 15-20 minutes. The dump1090 container kept restarting every 2-5 minutes, so I added a restart policy line compatible with docker-compose up and relaunched it that way. FA, FR24, and dump1090 are all running under docker-compose up but none have died yet, so I don't know if the corrected restart parameter is working.

New in version 3.7 of docker-compose (changelog) is the init feature.

The dump1090/Dockerfile-dump1090 should be updated to use it over the custom tini install.

https://docs.docker.com/compose/compose-file/

Running adsbexchange-mlat the following error occurs:

/usr/bin/mlat-client-runner: line 21: mlat-client: Permission denied

I pulled the ..virtualradar:dev image and get 'standard_init_linux.go:222: exec user process caused "exec format error" ' error on start and the container exits - this is an x86/x64 architectiure synology nas.

At current docker multistage builds cache poorly and slow down the build and development process.

moby/moby#34715

At current Docker picks the wrong ARM images (armhf vs armel) on many ARM boards (eg. Raspberry PI).

To work around this the Docker files specify a fixed architecture tag. eg:

In general this project should support both ARM and x86 with all variants there in.

Docker bug: moby/moby#34875
Forks just to fix this issue: https://github.com/fl0wfr/docker-ads-b/commit/34cfab548187f9bb9200ec4cf98069b0761dd6d4

While building virtualradar I'm seeing a bunch of errors about pip being outdated. It is suggesting running pip update pip to correct it.

VirtualRadaSserver v2.4.3 has been released and should be upgraded in the Docker images

http://www.virtualradarserver.co.uk/Download.aspx
https://twitter.com/VRadarServer/status/1155247312538656779?s=03

Hello, and thanks for putting this together.

I assume the general instructions are to git clone this repo, edit the variables and then run "docker-compose up"?

Also, do you know if I can run watchtower on a Raspberry Pi to keep the various containers up to date?

Thanks again.