piaware restart of dump1090

I have an issue originating with an unstable clock but know this is probably hardware related. I’ll debug and figure out the offending hardware; that is not the purpose of this post.

When I encounter the unstable clock issue, I see in the logs that dump1090 stops sending to piaware and eventually piaware attempts to repair the system and restart dump1090 (which BTW a service restart does resolve the lack of sending). The problem however is that piaware is unable to locate the service if I’m interpreting the log message correctly, but the very next line is references ‘dump1090-mutabi’.

Feb 26 23:35:00 piaware piaware[522]: attempting to restart dump1090..
Feb 26 23:35:01 piaware piaware[522]: can't restart dump1090, no services that look like dump1090 found
Feb 26 23:35:11 piaware piaware[522]: ADS-B data program 'dump1090-mutabi' is listening on port 30005, so far so good

The question is why can’t piaware find the service? Manually, I’m able to restart dump1090-mutability.service via systemctl or the service command.

Related to permissions? (Don’t think so, but…?)
#allow-auto-updates no # using default value
allow-manual-updates yes # value set at /boot/piaware-config.txt:4

My setup is via package installs: Piaware 3.3.0 and dump1090-mutability 1.15~dev on RPi2 v1.1 and using blue FA dongle (amp/filter).

The logic lives in /usr/lib/piaware_packages/fa_services.tcl

What does “systemctl list-unit-files --no-legend --no-pager ‘dump1090*’” say?

It returns nothing.

However systemctl status dump1090* returns,

 systemctl status dump1090-*
● dump1090-mutability.service - LSB: dump1090 daemon (mutability variant)
   Loaded: loaded (/etc/init.d/dump1090-mutability)
   Active: active (running) since Mon 2017-02-27 16:57:44 UTC; 3h 37min ago
  Process: 14464 ExecStop=/etc/init.d/dump1090-mutability stop (code=exited, status=0/SUCCESS)
  Process: 14473 ExecStart=/etc/init.d/dump1090-mutability start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/dump1090-mutability.service
           └─14482 /usr/bin/dump1090-mutability --measure-noise --net --device-index 07000000 --g...

● dump1090-fa.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

I guess this is some kind of LSB / systemd interaction then. piaware tries to find a dump1090 service via list-unit-files if systemd is running.

Maybe list-units --all works better in more cases?

I think you are correct. A quick test of some other systemd commands reveal more that don’t return results as I would have expected, e.g., is-enabled vs. is-failed vs. is-active.

Thanks as always for your insight.

Need some help …
Due to a SD-Card failure, I installed again piaware-sd-card-3.5.3.img on a new fresh 16 GB card. Everything is running (WLAN, access via ssh, etc.) except dump1090-fa will not start, only the spinning wheel is turning around … :slightly_frowning_face:

Status reports as follows

pi@MB08:~$ sudo piaware-status
PiAware master process (piaware) is running with pid 581.
PiAware ADS-B client (faup1090) is not running.
PiAware mlat client (fa-mlat-client) is not running.
Local ADS-B receiver (dump1090) is not running.

no program appears to be listening for connections on port 30005.
faup1090 is NOT connected to the ADS-B receiver.
piaware is connected to FlightAware.

got ‘couldn’t open socket: connection refused’
dump1090 is NOT producing data on localhost:30005.

Your feeder ID is xxx




pi@MB08:~$ systemctl status dump1090*
● dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization)
Loaded: loaded (/lib/systemd/system/dump1090-fa.service; enabled)
Active: activating (auto-restart) (Result: exit-code) since Mon 2017-12-18 20:36:17 UTC; 18s ago
Docs: PiAware - ADS-B and MLAT Receiver - FlightAware
Process: 1981 ExecStart=/usr/bin/dump1090-fa $RECEIVER_OPTIONS $DECODER_OPTIONS $NET_OPTIONS $JSON_OPTIONS $PIAWARE_DUMP1090_LOCATION_OPTIONS --write-json /run/dump1090-fa --quiet (code=exited, status=1/FAILURE)
Main PID: 1981 (code=exited, status=1/FAILURE)


my question: how can I get dump1090-fa (SKYVIEW) running (again) ??

I’m trying since hours several ‘tricks’, no one works …
… maybe it’s very simple and I can’t see it …

Check you dongle by following method

#First install required test package
sudo apt-get install rtl-sdr

#Now run the test of DVB-T/ProStick dongle
sudo killall dump1090-fa
sudo rtl_test -t

Post output genrated by command sudo rtl_test -t

thanx for your quick reply … :smiley:

(EDIT) First, my RasPiZero is connected to RTL2832U DVBT-Stick.

and here’s my output:
pi@MB08:~$ sudo apt-get install rtl-sdr
Reading package lists… Done
Building dependency tree
Reading state information… Done
rtl-sdr is already the newest version.
rtl-sdr set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
pi@MB08:~$ sudo killall dump1090-fa
dump1090-fa: no process found
pi@MB08:~$ sudo rtl_test -t
No supported devices found.

Sorry, the orange stick + filter is connected to my RasPi3; my Zero is connected to a RTL2832U R820T DVBT-Stick.

Your dongle connected to Pi Zero (MB08) is NOT working. Unplug it and then replug and reboot Pi. If this does not work, unplug it and replug in another USB port, and reboot Pi. Most likely this will fix connection issues.

If all this does not fix the problem, then most likely your Orange dongle is defective or DC power adaptor is bad.


The Orange Pro Stick is actually DVB-T (RTL2832U R820T) + Amplifier. The rtl_test -t will give identical output for both DVB-T and Orange Pro Stick, except that the serial # of DVB-T is 00000001 and that of Orange Pro Stick is 00001000.

Here is output generated by my Orange Pro Stick

sudo killall dump1090-fa
sudo rtl_test -t

Found 1 device(s):
  0:  Realtek, RTL2832U, SN: 00001000

Using device 0: Generic RTL2832U
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 
8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 
29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 
44.5 48.0 49.6
Sampling at 2048000 S/s.
No E4000 tuner found, aborting.

I follewd your advce and again:

So, two things:
a) no dump1090-fa found (to kill)
b) no device (stick/receiver) found

… and: the PiZero has only ONE USB port …

now it’s late, 11:20 PM …

Many thanx for your patience and support … I’ll try more tomorrow …

If you have connected dongle to Pi Zero using a USB extender cable, then remove cable and plug the dongle directly into Pi Zero’s USB port. Often USB extender cable cause such problems.

Problem is, the Pi0 uses micro USB ports.

Oh! I did not realize this.

So you have to use a microUSB to USB adapter cable. Well this one may be the cause of problem. If you have another such cable, try it, but first plugout Orange dongle from your Pi3, and plug into Pi Zero and reboot Pi Zero. This will determine if it is dongle or cable which is faulty.

huuuh … my fault … :see_no_evil: … now it works …

Connection stick-to-PiZero is established via a short USB-USB cable and an USB-microUSB-Adapter.
The short USB cable wasn’t plugged in “deep enough” into the adapter, hahaha … :blush:

But I’m still wondering, why command “killall dump1090-fa” said “no dump1090-fa found” …

Thx again for your support – normally I put an eye on all connections first … :roll_eyes:

Glad to know that you found and fixed the problem.

The command “sudo killall dump1090-fa” kills all the running instances of dump1090-fa. As the dump1090-fa has already failed (due to missing dongle) and no more running, the command did not find any running instance of dump1090-fa, and gave output “dump1090-fa: no process found”. This output does NOT mean the software dump1090-fa is NOT installed on your Pi. It only tells that there is “currently no running instance of dump1090-fa”

When dongle is working and dump1090-fa is running, issuing this command will silently kills it and will NOT give any output. You can then check its success by command sudo systemctl status dump1090-fa -l

sudo systemctl status dump1090-fa -l
#Last 3 lines of output are:
  Caught SIGTERM, shutting down..
  Waiting for receive thread termination
  Normal exit.

To check if dump1090-fa is installed or not, use command apt-cache policy dump1090-fa

apt-cache policy dump1090-fa

  Installed: 3.5.3
  Candidate: 3.5.3
  Version table:
 *** 3.5.3 0
        500 http://flightaware.com/adsb/piaware/files/packages/ jessie/piaware armhf Packages
        100 /var/lib/dpkg/status

@ abcd567,

many thanks again for your additional information … :+1: