RBFeeder on RPi has memory leak with UAT

Started by josh, June 15, 2020, 07:03:03 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

josh

Using RBFeeder Version 20200423004254 on my RPi3.
The RPi crashed after 2 days run by memory overflow after enabling UAT feed via dump978-fa.
Here is the memory consumption of RBFeeder after 27.5 hours run.

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
17289 root      20   0  584672 473172   4884 S   4.1  52.8  27:28.94 rbfeeder



No web-site explains this situation, please help.

There are the facts that may help someone tries to reproduce the issue.

  • Using dump978-fa not dump978-rb.
  • The leaking rate is much less if UAT is disabled or no traffic on UAT.
  • My UAT stream contains many TIS-B.
Thank you.

PattyManser

Hi...If you select DVBT (USB), FR24 feeder will start its own dump1090 at startup and grab the DVBT. Your dump1090-mutability will become orphan - no dongle left for it.
The FR24 feeder starts/stops and passes these arguments at startup ONLY to the dump1090 provided by FR24.

abcd567

#2
Quote from: josh on June 15, 2020, 07:03:03 PM
Using dump978-fa not dump978-rb.

Please post output of following 3 command to see what are your settings.
NOTE: The output of first command contains your RB24 key. Remove your key when posting here.

cat /etc/rbfeeder.ini 



systemctl status dump978-rb



systemctl status dump978-fa

josh

I'm trying to answer your question with long text, but following message generated.
CleanTalk: *** Forbidden. Message seems to be spam. ***

So I have a quick question.
I'm using the port 30979 of dump978-fa. Is it correct?  There is another port 30978.

josh

Thank you PattyManser,
My 1090MHz feeding works well. The issue starts after enabling 978MHz UAT with:

[dump978]
dump978_enabled=true
dump978_port=30979


I posted in another reply. I guess the 30979 may have an issue.
Thank you.

Quote from: PattyManser on June 26, 2020, 04:40:23 PM
Hi...If you select DVBT (USB), FR24 feeder will start its own dump1090 at startup and grab the DVBT. Your dump1090-mutability will become orphan - no dongle left for it.
The FR24 feeder starts/stops and passes these arguments at startup ONLY to the dump1090 provided by FR24.

josh

I've just switched dump978-fa to dump978-rb,  and starts checking memory usage.

piaware seems to be able to read from dump978-rb json output.
It may be a solution of memory leaking.

Thank you for your helping.

abcd567

Your following setting to feed rbfeeder from Flightaware's dump978-fa are perfect:

[dump978]
dump978_enabled=true
dump978_port=30979


The memory problem is caused because you have both tbe dump978-fa & dump978-rb installed and running.

Since the dongle is grabbed by Flightaware's dump978-fa, the RB24's dum978-rb runs dongle-less, and keeps restarting continously, causing excessive use of cpu and memory.

To solve this problem, uninstall RB24's dump978-rb, and reboot the Pi
Note: Do NOT change above noted settings in file/etc/rbfeeder.ini

sudo apt purge dump978-rb   

sudo reboot   





josh

Quote from: abcd567 on June 27, 2020, 05:53:49 AM
The memory problem is caused because you have both tbe dump978-fa & dump978-rb installed and running.

Since the dongle is grabbed by Flightaware's dump978-fa, the RB24's dum978-rb runs dongle-less, and keeps restarting continously, causing excessive use of cpu and memory.

I disabled dump978-rb by

$ sudo systemctl disable dump978-rb


I believe my dump978-rb never wake up.

$ sudo systemctl status dump978-rb
œ dump978-rb.service - dump978 ADS-B UAT receiver
   Loaded: loaded (/lib/systemd/system/dump978-rb.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: https://www.radarbox.com


Should I try to uninstall dump978-rb completely ?

I'm trying to run dump978-rb only.
This is the status after 6 hours. rbfeeder already uses 18.3% = 190MB memory.
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
14236 root      20   0  273952 164104   5696 S   1.0  18.3   6:24.33 rbfeeder
13818 dump978   15  -5  101676  24320  16256 S  25.9   2.7 103:34.88 dump978-rb
11187 dump1090  15  -5   31520  11740   2344 S  12.6   1.3 616:16.27 dump1090-fa

It seems not to improve.
I'm using cron to restart rbfeeder twice a day. It works but not smart.
Thank you.

abcd567

#8
Maybe some files got corrupted. Try uninstall, then reinstall rbfeeder.



sudo apt purge rbfeeder

sudo apt install rbfeeder

## Edit file /etc/rbfeeder.ini
## Configure rbfeeder to use Flightaware's dump978-fa.
## Reboot
sudo reboot

josh

I did install again..,  seems same,  rbfeerer grows bigger and bigger.

And I encounter new issue my mlat-client is not running.
There is no process of /usr/bin/mlat-client, but nothing reported from rbfeeder log.
This process is launched by /usr/bin/rbfeeder ?

josh

The mlat-client issue has been resolved.
rbfeeder was not convenient due to no error message was generated with any configuration problem.

abcd567

#11
Quote from: josh on June 27, 2020, 09:13:35 PM
The mlat-client issue has been resolved.

How?

Quote from: josh on June 27, 2020, 09:13:35 PM
rbfeeder was not convenient due to no error message was generated with any configuration problem.

Try this command to find any issues:

sudo journalctl -u rbfeeder --no-pager   

josh

Quote from: abcd567 on June 28, 2020, 03:30:19 AM
Quote from: josh on June 27, 2020, 09:13:35 PM
The mlat-client issue has been resolved.
How?
Yeah I love journalctl generally, but rbfeeder + mlat case has no useful record of mlat command line output.
My case was a wrong elevation description with fractional vale like nn.n .
It makes mlat launch failure quietly.
Fortunately I was happy to solve it soon.

So I would like to return original topic.
I tried some filter of 30979 stream. This seems there is no message type dependency of leaking.  In other words, every message has a little leak.


abcd567

#13
Yes, rbfeeder does not have a good error logging. Many errors are silent.

How did you install mlat-client? The command "sudo apt install mlat-client" used to fail on Buster. Is it working now?

Which Pi model and OS you are using?
I have piaware sd card image 3.8.1 (buster) on RPi model 2 and 64-bit Raspbian Buster on RPi model 4, and have rbfeeder on both working with mlat fine. On piaware sd card, I have dump978-fa which also feeds rbfeeder using "/etc/rbfeeder.ini" setting "dump978_port=30979".

josh

Thank you continuous reply. I saw you in many threads. dump978_port= idea was also from your thread! Thank you again.

I'm using piaware on Raspbian buster "32bit" armv71,  RPi3 model B rev1.2 .  oh, 64 bit OS is available?
At rbfeeder installing, I had a trouble with enabling mlat, but the reason was another version of Python in my Pi. I guess the clean install with the instruction described in official web would work well.  I saw an option the installer asking if dump978-rb install or not. This is nice option can avoid dump978-rb confliction.