# Restart dump1090

**URL:** <https://discussions.flightaware.com/t/restart-dump1090/88306>\
**Category:** ADS-B Flight Tracking\
**Created:** [June 9, 2023, 3:24pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306 "2023-06-09T15:24:42Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![baqwas](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/baqwas/32/113638_2.png) [@baqwas](https://discussions.flightaware.com/u/baqwas)\
**Post date:** [June 9, 2023, 3:24pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/1 "2023-06-09T15:24:42Z")

</div>

Hello!

One of my RPi0 installations is having _hiccups_ recently despite no change in infrastructure or location except for the periodic update/upgrade headless interventions. It appears that **dump1090** stops working intermittently.

I found an old (_circa_ 2014) command in this forum to restart dump1090 if it has stopped:

```auto
/etc/init.d/dump1090.sh start

```

Unfortunately, this command does not run on my installation (presumably owing to changes in running daemons in the more recent versions of the OS):

```auto
 `+oooooooooooo: `+oooooooooooo: OS: Raspbian GNU/Linux 11 (bullseye) armv 
  /oooo++//ooooo: ooooo+//+ooooo. Host: Raspberry Pi Zero 2 W Rev 1.0 
  `+ooooooo:-:oo- +o+::/ooooooo: Kernel: 6.1.21-v7+ 
   `:oooooooo+`` `.oooooooo+- Uptime: 13 mins 
     `:++ooo/. :+ooo+/.` Packages: 1422 (dpkg) 
        ...` `.----.` ``.. Shell: bash 5.1.4 
     .::::-``:::::::::.`-:::-` Resolution: 1920x1200 
    -:::-` .:::::::-` `-:::- Terminal: /dev/pts/0 
   `::. `.--.` `` `.---.``.::` CPU: BCM2835 (4) @ 1.000GHz 
       .::::::::` -::::::::` ` Memory: 172MiB / 426MiB 
 .::` .:::::::::- `::::::::::``::. CPU Usage: 26% 
-:::` ::::::::::. ::::::::::.`:::- Disk (/): 7.2G / 59G (13%)

```

What are the simplest commands to check if dump1090 is running and to restart it if it is not? Thanks.

Regards.

---

<div class="post-metadata">

**Author:** ![Jonseyt23](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/jonseyt23/32/125135_2.png) [@Jonseyt23](https://discussions.flightaware.com/u/Jonseyt23)\
**Post date:** [June 9, 2023, 3:28pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/2 "2023-06-09T15:28:20Z")

</div>

Try sudo systemctl restart dump1090 or sudo systemctl restart dump1090-fa if flightaware image to restart and sudo systemctl status dump1090 or sudo systemctl status dump1090-fa

I’m only advising from what I use on the fa image but I’m no specialist when it comes to RPI lol

---

<div class="post-metadata">

**Author:** ![baqwas](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/baqwas/32/113638_2.png) [@baqwas](https://discussions.flightaware.com/u/baqwas)\
**Post date:** [June 9, 2023, 4:04pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/3 "2023-06-09T16:04:23Z")

</div>

Thanks, @Jonseyt23!

Your suggestion makes sense since _restart_ is the option I use for other services.

Regards.

---

<div class="post-metadata">

**Author:** ![baqwas](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/baqwas/32/113638_2.png) [@baqwas](https://discussions.flightaware.com/u/baqwas)\
**Post date:** [June 11, 2023, 2:33pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/4 "2023-06-11T14:33:57Z")

</div>

I managed to get it up and running for a short while but then the issue(s) recurred:

```auto
$ piaware-status
PiAware master process (piaware) is running with pid 9632.
PiAware ADS-B client (faup1090) is not running.
PiAware ADS-B UAT client (faup978) is not running (disabled by configuration settings)
PiAware mlat client (fa-mlat-client) is not running.
Local ADS-B receiver (dump1090) is not running.

no program appears to be listening for ES 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.

```

Also, I messed up the **systemctl** command. Which one(s) should I use (to have my _custom_ restart)? The command line **top** utility displays **piaware** as consuming \< 2% CPU cycles. **dump978-fa** shows up at the 6% utilization range when given the slice by the OS presumably.

```auto
$ sudo systemctl restart faup1090
Failed to restart faup1090.service: Unit faup1090.service not found.
$ sudo systemctl restart dump1090
Failed to restart dump1090.service: Unit dump1090.service not found.
$

```

---

<div class="post-metadata">

**Author:** ![tomvdhorst](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/tomvdhorst/32/137059_2.png) [@tomvdhorst](https://discussions.flightaware.com/u/tomvdhorst)\
**Post date:** [June 11, 2023, 3:14pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/5 "2023-06-11T15:14:36Z")

</div>

use this command, the processname is dump1090-fa

sudo service dump1090-fa restart

Dump1090-fa is run as a service so that 's what you need to restart.

to check the status:  
sudo service dump1090-fa status

To stop  
sudo service dump1090-fa stop

To start  
sudo service dump1090-fa start

---

<div class="post-metadata">

**Author:** ![baqwas](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/baqwas/32/113638_2.png) [@baqwas](https://discussions.flightaware.com/u/baqwas)\
**Post date:** [June 11, 2023, 3:40pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/6 "2023-06-11T15:40:01Z")

</div>

Thanks, @tomvdhorst!

Your suggestions will help me to streamline my _newbie_ bash script. Hopefully, (big hope, of course) I’ll patch an NRPE plugin to streamline the monitoring (and restart).

Regards.

---

<div class="post-metadata">

**Author:** ![baqwas](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/baqwas/32/113638_2.png) [@baqwas](https://discussions.flightaware.com/u/baqwas)\
**Post date:** [June 12, 2023, 2:24pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/7 "2023-06-12T14:24:53Z")

</div>

Before I get a new (and improved) Pro Stick (with the in-built filter), I’d like to run by my observations with the wider audience, please:

Here are the _official_ troubleshooting recommendations:

> There are multiple reasons that the timing information may be bad. The most common explanations are:  
> 1. The USB cable is dropping information. This usually occurs when you are using low quality USB extension cables. Try connecting the RTL-SDR (e.g., Pro Stick) directly to the Raspberry Pi’s USB port.  
> 2. The power supply is not supplying enough power. Try another 5V USB power supply.  
> 3. The receiver location is not set correctly. The server-side MLAT timing calculations depend on knowing your receiver location. Go to your FlightAware “My ADS-B” page and set your location (click the gear icon).  
> 4. The RTL-SDR (e.g., Pro Stick) is dropping information. Try a different RTL-SDR device.  
> 5. The clock chip on the RTL-SDR device is bad. Try a different RTL-SDR device.

My logs have the following entries even after:

`$ sudo service dump1090-fa restart`

```auto
Jun 12 08:40:50 raspbari15 piaware[601]: mlat-client(28502): Lost connection to localhost:30005
Jun 12 08:40:50 raspbari15 piaware[601]: mlat-client(28502): Reconnecting in 30.0 seconds
Jun 12 08:40:50 raspbari15 piaware[601]: lost connection to dump1090-fa via faup1090
Jun 12 08:40:50 raspbari15 piaware[601]: faup1090 exited normally
Jun 12 08:40:50 raspbari15 piaware[601]: will reconnect to dump1090-fa in 30 seconds

```

Steps 1-3 didn’t remediate the issue.

Is the replacing the Pro Stick the only remaining viable option (Steps 4-5)? Thanks.

Regards.

---

<div class="post-metadata">

**Author:** ![tomvdhorst](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/tomvdhorst/32/137059_2.png) [@tomvdhorst](https://discussions.flightaware.com/u/tomvdhorst)\
**Post date:** [June 12, 2023, 3:50pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/8 "2023-06-12T15:50:16Z")

</div>

Maybe you should start by telling what you are using now and how you are trying to get this running. The messages indicate a loss of the connection to the stick.  
What stick are you using, how is it connected etc etc. Then we can determine from there if there’s something that can aid you in the fix. And yes sometimes sticks break down so that could be a cause but first we need to rule out other possibilities.

---

<div class="post-metadata">

**Author:** ![baqwas](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/baqwas/32/113638_2.png) [@baqwas](https://discussions.flightaware.com/u/baqwas)\
**Post date:** [June 12, 2023, 4:53pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/9 "2023-06-12T16:53:25Z")

</div>

Thanks again for the continuing guidance.

**Hardware** :  
Antenna (table-top dipole) → Pro Stick → OTG Hub (SMAYS) → RPi 0 2 (headless)  
Intranet → OTG

**Platform**  
OS: Raspbian GNU/Linux 11 (bullseye) armv7l  
Host: Raspberry Pi Zero 2 W Rev 1.0  
Kernel: 6.1.21-v7+  
CPU: BCM2835 (4) @ 1.000GHz  
Memory: 88MiB / 426MiB  
CPU Usage: 15% (immediately after boot)  
Disk (/): 7.3G / 59G

My initial troubleshooting efforts (prior to posting the 1st message at this forum) involved:

- Changing LAN cables
- Using a different port on the (_unmanaged_) network switch
- Using a different (_managed_) network switch
- Connecting to main network switch directly (current operation mode)
- Changing OTG hub (heard many stories about this specific cheap SKU but I have many in productive use currently that have never failed but some do get hot)
- Rebooting the computer after update/upgrade (and sometimes just after restarting the relevant services as a precautionary step)
- No known (or recorded) power surge; even though transformer based UPS units protect the infrastructure power requirements, there are no “surge protectors” for the LAN cable (just dangling a red herring here)

None of these steps resolved the issue. Some additional observations:

- Wasn’t able to monitor the computer a month or so ago (_i.e._ computer was periodically going offline)
- However, Nagios (network monitoring software) has not recorded a single issue regarding simple connectivity since the first alert from FA central a week or so ago
- Can SSH to computer without issue and examine **piaware** status
- The only other Pro Stick at hand is committed to another **piaware** instance (_i.e._ do not want to swap)

I’d love to learn more about troubleshooting so that I have something to tinker with. In the meantime, I have placed an order for Pro Stick® Plus!

Regards.

---

<div class="post-metadata">

**Author:** ![tomvdhorst](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/tomvdhorst/32/137059_2.png) [@tomvdhorst](https://discussions.flightaware.com/u/tomvdhorst)\
**Post date:** [June 12, 2023, 5:09pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/10 "2023-06-12T17:09:41Z")

</div>

Some observations:

When the service stops, observe the logging. Not just from the dump1090-fa service but all.  
Is there any indication that maybe the OS is causing the issue ?  
Random going offline spikes the interest there. What is causing it ?  
Is there a heat problem ?

Alternative, prepare a 2nd SD card with the software loaded.  
Swap the card, check if the problem persists.  
If so the issue is probably hardware related. If the issue disappears it is software related or your SD card is failing.  
From there on you can eliminate possible causes and zoom in to find the culprit of your problem.

---

<div class="post-metadata">

**Author:** ![baqwas](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/baqwas/32/113638_2.png) [@baqwas](https://discussions.flightaware.com/u/baqwas)\
**Post date:** [June 12, 2023, 5:21pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/11 "2023-06-12T17:21:29Z")

</div>

Excellent observation about the SD card. Good point.

I’ll prepare a clean SD card image and resume the troubleshooting. Thanks.

Regards.

P.S.  
Unimportant for now, but I do have the (blue) FA Filter before the Pro Stick.

---

<div class="post-metadata">

**Author:** ![tomvdhorst](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/tomvdhorst/32/137059_2.png) [@tomvdhorst](https://discussions.flightaware.com/u/tomvdhorst)\
**Post date:** [June 12, 2023, 5:23pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/12 "2023-06-12T17:23:06Z")

</div>

The filter is completely passive so that can be ruled out as a cause 😉

---

<div class="post-metadata">

**Author:** ![victorbravo77](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/victorbravo77/32/137187_2.png) [@victorbravo77](https://discussions.flightaware.com/u/victorbravo77)\
**Post date:** [June 12, 2023, 7:15pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/13 "2023-06-12T19:15:09Z")

</div>

Or a failing power supply?

I was impressed to learn how much of a factor a sketchy power supply can be.

(thanks, again @obj)

---

<div class="post-metadata">

**Author:** ![baqwas](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/baqwas/32/113638_2.png) [@baqwas](https://discussions.flightaware.com/u/baqwas)\
**Post date:** [June 12, 2023, 7:31pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/14 "2023-06-12T19:31:54Z")

</div>

Hello @tomvdhorst et al.,

Many, many thanks for the guidance. It was the SD Card!! Re-built on another card and the system has been stable for more than that during previous cycles:

```auto
$ piaware-status
PiAware master process (piaware) is running with pid 567.
PiAware ADS-B client (faup1090) is running with pid 1413.
PiAware ADS-B UAT client (faup978) is not running (disabled by configuration settings)
PiAware mlat client (fa-mlat-client) is running with pid 1079.
Local ADS-B receiver (dump1090-fa) is running with pid 1287.

dump1090-fa (pid 1287) is listening for ES connections on port 30005.
faup1090 is connected to the ADS-B receiver.
piaware is connected to FlightAware.

dump1090 is producing data on localhost:30005.

```

Now I will have an extra Stick shortly. Will have to wait for a local retailer to provide the RPi0 **2** (been waiting for one since Aug '21).

Regards.

---

<div class="post-metadata">

**Author:** ![baqwas](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/baqwas/32/113638_2.png) [@baqwas](https://discussions.flightaware.com/u/baqwas)\
**Post date:** [June 12, 2023, 7:40pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/15 "2023-06-12T19:40:57Z")

</div>

Yes, your observation is correct. The RPi4 power supply demands (and the quality of the products) provide hands-on lessons for those of us who want to wade into the weeds.

Nearly 20 years ago, I was given a tear down on why “Compaq” power supplies (for notebooks) were more expensive than the ones from Round Rock. The consumer could care less about the “over engineering” of the Compaq PS (for EMI protection) but gravitated towards the competitor’s products because they were inevitably $10+ cheaper. Sorry, off-topic but your reply trigger a reflex response on my part. The notebooks incidentally were assembled by the same ODM.

---

<div class="post-metadata">

**Author:** ![tomvdhorst](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/tomvdhorst/32/137059_2.png) [@tomvdhorst](https://discussions.flightaware.com/u/tomvdhorst)\
**Post date:** [June 12, 2023, 7:53pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/16 "2023-06-12T19:53:11Z")

</div>

Good to hear you found the issue. Now catch some aircraft 🥳👍🏻😉

---

<div class="post-metadata">

**Author:** ![victorbravo77](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/victorbravo77/32/137187_2.png) [@victorbravo77](https://discussions.flightaware.com/u/victorbravo77)\
**Post date:** [June 12, 2023, 8:12pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/17 "2023-06-12T20:12:57Z")

</div>

Nice. All I had at my disposal were 8088 atx machines in the 80s. And MS DOS.

I use a p3b+ and solely dedicate it to [victorbravo77 ADS-B Feeder Statistics - FlightAware](http://flightaware.com/adsb/stats/user/victorbravo77)

---

<div class="post-metadata">

**Author:** ![baqwas](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/baqwas/32/113638_2.png) [@baqwas](https://discussions.flightaware.com/u/baqwas)\
**Post date:** [June 12, 2023, 9:32pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/18 "2023-06-12T21:32:45Z")

</div>

So did you _dabble_ with ASM too? (to extend INT _handlers_)

---

<div class="post-metadata">

**Author:** ![victorbravo77](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/victorbravo77/32/137187_2.png) [@victorbravo77](https://discussions.flightaware.com/u/victorbravo77)\
**Post date:** [June 14, 2023, 11:11pm UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/19 "2023-06-14T23:11:18Z")

</div>

Assembly? No, I never learned that level of code. Like I said, DOS and maybe some basic. That’s it.

---

<div class="post-metadata">

**Author:** ![fhmiii](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/fhmiii/32/119130_2.png) [@fhmiii](https://discussions.flightaware.com/u/fhmiii)\
**Post date:** [November 4, 2023, 3:26am UTC](https://discussions.flightaware.com/t/restart-dump1090/88306/20 "2023-11-04T03:26:26Z")

</div>

I’ve been trying to adjust gain and I added @wiedehopf’s autogain script after seeing a significant drop in reception this afternoon. Since adding it, I haven’t been able to view the standard Flight Aware web interface. It gives me a 403 Forbidden error (Sky Aware works, though). I tried to restart dump1090 and it tells me the service is masked.

> [user]@raspberrypi:~ $ piaware-status  
> PiAware master process (piaware) is running with pid 670.  
> PiAware ADS-B client (faup1090) is running with pid 23299.  
> PiAware ADS-B UAT client (faup978) is not running (disabled by configuration settings)  
> PiAware mlat client (fa-mlat-client) is running with pid 1508.  
> Local ADS-B receiver (dump1090) is not running.
> 
> readsb (pid 23268) is listening for ES connections on port 30005.  
> faup1090 is connected to the ADS-B receiver.  
> piaware is connected to FlightAware.
> 
> dump1090 is producing data on localhost:30005.
> 
> Your feeder ID is b1040fc2-769f-4d06-9e4d-356a5c4abb5d (from /var/cache/piaware/feeder\_id)  
> [user]@raspberrypi:~ $ sudo service dump1090-fa restart  
> Failed to restart dump1090-fa.service: Unit dump1090-fa.service is masked.

Anyone have any ideas?

[Next page](https://discussions.flightaware.com/t/restart-dump1090/88306.md?page=2)
