Dump1090 exited with error code

This morning i realized that my device was running, but dump1090-fa died. Checking the service i got this:

* dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization)
   Loaded: loaded (/lib/systemd/system/dump1090-fa.service; enabled; vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Sun 2020-03-22 08:40:16 CET; 8s ago
     Docs: https://flightaware.com/adsb/piaware/
  Process: 29635 ExecStart=/usr/share/dump1090-fa/start-dump1090-fa --write-json /run/dump1090-fa --quiet (code=exited, status=1/FAILU
 Main PID: 29635 (code=exited, status=1/FAILURE)

Tried restarting the service with sudo systemctl restart dump1090-fa but ended up with the same result.
Only a full reboot solved the issue.

Any ideas what caused this?

Is dongle ok?

sudo apt install rtl-sdr
sudo systemctl stop dump1090-fa  
rtl_test -t  
rtl_adsb

The logs will tell you why dump1090 exited, you should look at them.

The stick is fine, after that problem it worked again without issues.

Logs simply say that no device was found. Have these entries after i performed the reboot
Why did it fail without changing something and why is it working again now?

Mar 22 08:34:35 Raspi4 systemd[1]: Stopped dump1090 ADS-B receiver (FlightAware customization).
Mar 22 08:34:35 Raspi4 systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
Mar 22 08:34:35 Raspi4 dump1090-fa[27837]: Sun Mar 22 08:34:35 2020 CET  dump1090-fa 3.8.0 starting up.
Mar 22 08:34:35 Raspi4 dump1090-fa[27837]: rtlsdr: no supported devices found.
Mar 22 08:34:35 Raspi4 systemd[1]: dump1090-fa.service: Main process exited, code=exited, status=1/FAILURE
Mar 22 08:34:35 Raspi4 systemd[1]: dump1090-fa.service: Failed with result 'exit-code'.
Mar 22 08:35:06 Raspi4 systemd[1]: dump1090-fa.service: Service RestartSec=30s expired, scheduling restart.
Mar 22 08:35:06 Raspi4 systemd[1]: dump1090-fa.service: Scheduled restart job, restart counter is at 69.

Dongle isn’t visible on the USB bus; probably a hardware fault.

An idea to try a different slot if it happens next time?

Currently it’s running without issues since this morning where the fault came up.
Or maybe the USB controller intermittent faulty?

Exact this problem happened with me few days ago on Ubuntu on my Desktop PC. Re-plugging and rebooting did not solve the problem. Changing USB slot (from back slots to front slots of PC) solved the problem.

NOTE:
The problem was NOT due to VM. Ubuntu was booted directly from hard drive (I have dual boot system Win 8 / Ubuntu 18 and can choose one at boot).

Assuming you have the same stick, the capacitors mentioned in the thread below might be an issue;

Thanks for your suggestions. I will monitor it and try a different slot if it comes up again.

A bit unclear why it was running without issues, then it stopped, after 30 Minutes i rebooted and now it’s running again since > 12 hours.

Anyways, not mission critical nowadays.
I also have a different stick which i could exchange with my secondary receiver.

just popped in my mind:
The device is also outside, but covered. However it could be also a temperature/humidity question.

Electrolytic capacitors tend to work less well when cold especially when they dry out with age/heat effects. Cold temperatures might just tip balance and affect stable operation of the dongle when cold.

It might even be a subtle issue as the combination of an ageing PI power supply and the dongle capacitors failing where under a very specific situation, the dongle crashes e.g. a spike in CPU usage might cause the dongle to experience a power dip that healthy capacitors in the dongle would otherwise guard against.

Of course, maybe it was just a one-off…hopefully!

The device runs since three months outdoor without that issue. I am using the original power supply for the Pi4 and never had it.
Currently we are around freezing point, but the device ran flawless during that period with much lower environment temperatures.

As the device is used for FA only, the CPU is more or less in almost idle mode.
The only thing that changes is the amount of flights due to the current situation regarding Covid-19.

Maybe it cools down because there is not much to do for it.
I keep an eye on it.

Some more log entries. Seem to be a “lost & found” :rofl: :joy:

Mar 23 07:57:39 Raspi4 dump1090-fa[879]: Found Rafael Micro R820T tuner
Mar 23 07:57:39 Raspi4 dump1090-fa[879]: rtlsdr: tuner gain set to 40.2 dB
Mar 23 07:57:39 Raspi4 dump1090-fa[879]: Allocating 4 zero-copy buffers
Mar 23 07:59:10 Raspi4 dump1090-fa[879]: cb transfer status: 1, canceling...
Mar 23 07:59:10 Raspi4 dump1090-fa[879]: rtlsdr: rtlsdr_read_async returned unexpectedly, probably lost the USB device, bailing out
Mar 23 07:59:10 Raspi4 dump1090-fa[879]: Mon Mar 23 07:59:10 2020 CET  Waiting for receive thread termination
Mar 23 07:59:10 Raspi4 dump1090-fa[879]: Reattaching kernel driver failed!
Mar 23 07:59:10 Raspi4 dump1090-fa[879]: Mon Mar 23 07:59:10 2020 CET  Abnormal exit.
Mar 23 07:59:10 Raspi4 systemd[1]: dump1090-fa.service: Main process exited, code=exited, status=1/FAILURE
Mar 23 07:59:10 Raspi4 systemd[1]: dump1090-fa.service: Failed with result 'exit-code'.

Something got wet and corroded.
Now causing intermittent issues.

With wind, rain can get into more places than you might think.

Hm, the device is fully covered by the roof and it is in a box with an additional cover. Rain would need to go upwards to hit it, mission impossible

If this is the case, it can be air humidity only.
However i am checking the connectors later

EDIT:
Today the device lost it’s USB stick exactly at the same time of yesterday. Wonder if this is by chance or something else kicked in. Since i rebooted again, it works without issues.

Only change i did was a gain increase from 40.2 to 42.1 after the reboot.

Today third day in a row having the issues in the morning hours.
I checked hardware physically, can’t detect anything, but corrosion is always hard to determine if it’s just started.

I changed the USB port now, monitoring.

Quick Update:

This morning the device went fine without any disruptions so far. The time of day of the last two days where it failed is already over.

Maybe that made the trick.