MLAT Segfault Crash about docker-fr24feed-piaware-dump1090 HOT 31 CLOSED

from docker-fr24feed-piaware-dump1090.

It looks like it's not possible to enable mlat for both fr24 and flightradar, I found some thread taking about this. The solution for now is to disable it for one of them. 😕

from docker-fr24feed-piaware-dump1090.

Hi,

Have you tried to reboot or disconnect and reconnect ? It look like a bug related to the connection not the software. 😕

from docker-fr24feed-piaware-dump1090.

[1935112.101844] usb 7-4: USB disconnect, device number 7
[1935118.287988] usb 7-1: new high-speed USB device number 8 using xhci_hcd
[1935171.912239] docker0: port 1(veth0e192b9) entered blocking state
[1935171.912241] docker0: port 1(veth0e192b9) entered disabled state
[1935171.912313] device veth0e192b9 entered promiscuous mode
[1935171.912468] IPv6: ADDRCONF(NETDEV_UP): veth0e192b9: link is not ready
[1935172.296789] eth0: renamed from veth37c0a06
[1935172.306883] IPv6: ADDRCONF(NETDEV_CHANGE): veth0e192b9: link becomes ready
[1935172.306967] docker0: port 1(veth0e192b9) entered blocking state
[1935172.306968] docker0: port 1(veth0e192b9) entered forwarding state
[1935289.740757] mlat_thread_mai[64325]: segfault at 63 ip 00001493af96d1b9 sp 00001493adafa6d0 error 4 in libnss_files-2.24.so[1493af96a000+a000]
[1935289.740763] Code: 31 c0 48 83 c4 58 5b 5d 41 5c 41 5d 41 5e 41 5f c3 e8 fb ef ff ff 4d 89 e5 49 89 c0 4c 8b 30 eb 04 49 83 c5 01 49 0f be 55 00 <41> f6 44 56 01 20 75 ef 84 d2 0f 84 67 ff ff ff 80 fa 23 0f 84 5e
[1935299.882682] veth37c0a06: renamed from eth0
[1935300.016428] docker0: port 1(veth0e192b9) entered disabled state
[1935300.070936] docker0: port 1(veth0e192b9) entered disabled state
[1935300.072005] device veth0e192b9 left promiscuous mode
[1935300.072006] docker0: port 1(veth0e192b9) entered disabled state

It seems like something with the new enabled mlat support is causing a segfault.

from docker-fr24feed-piaware-dump1090.

It seems I found the cause/bug. When I edit fr24feed.ini and change..

mlat="no"
mlat-without-gps="no"

and start the docker everything works as expected. Now I can even see the fr24 webui how many aircrafts I track and show them on the flightaware map.

from docker-fr24feed-piaware-dump1090.

I'll add a section in the readme to warn about this issue.
Thanks

from docker-fr24feed-piaware-dump1090.

I'll add a section in the readme to warn about this issue.
Thanks

Any solution to this problem yet ?
I would really like to enable mlat.

from docker-fr24feed-piaware-dump1090.

I'm also having this issue on the latest build. I've rolled back to tag 2.0 for the time being (although for some reason piaware isn't behaving now but I'll leave that offline for now, fr feed is working on 2.0).

from docker-fr24feed-piaware-dump1090.

After succesfully running a day or so with no mlat, I can see again in the docker logs the same error over and over.

from docker-fr24feed-piaware-dump1090.

I got the same issue, after a day or more it starts flooding the error.

from docker-fr24feed-piaware-dump1090.

Seems to be working again, after container update. Nice work !

from docker-fr24feed-piaware-dump1090.

@Technikte Working with or without mlat ?

from docker-fr24feed-piaware-dump1090.

Sorry, now a fully update..so it started without mlat ok and everything working, but now after a day the error pops up again in the logs and the feeder stopped working.

from docker-fr24feed-piaware-dump1090.

We need to see why it crash the first time.
I got the exacte same behaviour.

from docker-fr24feed-piaware-dump1090.

I created a new branch, it's start dump1090 alone and connect piaware and fr24feed to it with beast over tcp (port 30005).
When fr24feed crash (I don't know why yet) the process restart and it can continue feeding data.

https://github.com/Thom-x/docker-fr24feed-piaware-dump1090/tree/beast-tcp
Be aware, the configuration has changed to use beast.

from docker-fr24feed-piaware-dump1090.

I have also looked at this, and I think the issue is that frfeed24 don't like glibc 2.28. This is the version used in Debian Buster (which is currently used).
Reverting back to Debian Stretch solves this.

from docker-fr24feed-piaware-dump1090.

@fgihl This is sad, did you tried it ?

from docker-fr24feed-piaware-dump1090.

I tried reverting back to stretch and it works fine for me. I also created a pull request for you to look at.
Yes, this is unfortunately. I hope they fix the issue soon.

from docker-fr24feed-piaware-dump1090.

Ok thanks, in this case I'll merge your PR. 👍

from docker-fr24feed-piaware-dump1090.

Fixed by #16

from docker-fr24feed-piaware-dump1090.

Seems I made a mistake when testing this. Debian Stretch did not solve it :-(
Sorry for that.

from docker-fr24feed-piaware-dump1090.

No problem, we'll figure it out.

from docker-fr24feed-piaware-dump1090.

So I'm running latest docker image currently (I pull latest automatically via watchtower) and the current image is just resulting in the following log being spammed repeatedly:

[reader][i]Connecting to DVBT receiver via (exe:///usr/lib/fr24/dump1090 --net --write-json /usr/lib/fr24/public_html/data --raw)
[reader][i]Connected to the receiver, configuring
[reader][i]Configured, processing messages
Tue Mar  3 13:44:49 2020 UTC  dump1090-fa v3.8.0 starting up.
rtlsdr: no supported devices found.
[reader][i]Connection terminated
[main][i]Terminating child process 5030 with SIGTERM

Any thoughts? Is this just while you're debugging the issue? Anything I can do to help?

I'll try unplugging and replugging the USB receiver dongle later when I'm home in case it's a result of the watchtower update just losing the device.

from docker-fr24feed-piaware-dump1090.

Your issue is not the same as the one we have, it's strange...
Did you see the device from the host, for me I have :

$ lsusb
...
Bus 001 Device 005: ID 0bda:2832 Realtek Semiconductor Corp. RTL2832U DVB-T
...

For the moment I'm trying to isolate dump1090 from the other services.
If you have any idea why it's crashing that could help.

from docker-fr24feed-piaware-dump1090.

Looks like the host has lost the USB device which is strange. Not showing up in lsusb. I'll re-plug it later and report back - please disregard my post for now!

from docker-fr24feed-piaware-dump1090.

No problem, sorry for having so many build lately ^^.
I started doing my tests on beast-tcp

from docker-fr24feed-piaware-dump1090.

So I finally remembered to re-plug the USB dongle and as of the latest image I've been running fine (with mlat disabled in fr24feed,ini) for almost 12 hours.

Will continue to monitor, and I'll re-enable mlat later today and see how/if things change.

from docker-fr24feed-piaware-dump1090.

It looks like flightradar is working on a new release. I received version 1.0.25-1 from there support. Unfortunently, it's still the same issue.

from docker-fr24feed-piaware-dump1090.

With my branch, I have dump1090 as a stand alone service, it is working well (with no mlat for fr24).

from docker-fr24feed-piaware-dump1090.

I tested some more to solve this, but it looks like it's a bug in the fr24feed program. I think the only way to get mlat to work, is to use 1.0.18-5

I also found the following thread:
https://forum.flightradar24.com/forum/radar-forums/flightradar24-feeding-data-to-flightradar24/12105-how-to-set-up-a-feeder-using-64-bit-ubuntu-linux-on-intel-platform/page7
See post #99-103

Looks like they have the same problem. They also conclude that using 1.0.18-5 is the only way to get mlat to work :-(

from docker-fr24feed-piaware-dump1090.

I'm going to test with version 1.0.18-5 with MLAT for a bit and will merge the branch if it's OK.

from docker-fr24feed-piaware-dump1090.