# Piaware keeps crashing **URL:** \ **Category:** ADS-B Flight Tracking\ **Created:** [August 20, 2026, 9:15pm UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674 "2026-08-20T21:15:34Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Markbone100](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/markbone100/32/135774_2.png) [@Markbone100](https://discussions.flightaware.com/u/Markbone100)\ **Post date:** [August 20, 2026, 9:15pm UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/1 "2026-08-20T21:15:34Z")
Running piaware for 978 mhz monitoring, but it keeps randomly crashing. Have to unplug the power and plug it back in to (sometimes) fix it. May take multiple attempts to get it going. It may run for 5 days or as short as 5 minutes and the following happens as seen in the piaware status. pi@piaware:~ $ piaware-status PiAware master process (piaware) is running with pid 466. PiAware ADS-B client (faup1090) is not running (disabled by configuration settings) PiAware ADS-B UAT client (faup978) is not running. PiAware mlat client (fa-mlat-client) is not running. Local ADS-B UAT receiver (dump978) is not running. no program appears to be listening for UAT connections on port 30978. faup978 is NOT connected to the ADS-B UAT receiver. piaware is connected to FlightAware. got ‘couldn’t open socket: connection refused’ dump978 is NOT producing data on localhost:30978. Your feeder ID is 9647e392-7d94-47f7-a6c4-498fd56f8332 (configured at /boot/piaware-config.txt:84) I have tried multiple correct power supplies, different usb ports for the dongle and it still keeps crashing. I dont know if it could be a faulty sd card causing the programs to crash or what it could be. I have had in the past to reformat the card and completely reinstall piaware on it after something happens and it would show offline and completely unable to log in to it via its ip address. ---
**Author:** ![jimMerk2](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/jimmerk2/32/127232_2.png) [@jimMerk2](https://discussions.flightaware.com/u/jimMerk2)\ **Post date:** [August 20, 2026, 10:10pm UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/2 "2026-08-20T22:10:49Z")
I have a similar situation. – `dump978-fa` runs for a few days to a week or so and then stops with a red indicator. The only way to get it running again is with a reboot. Through the `dump978-fa` crashing, `dump1090-fa` and `piaware` continue to run normally. So I don’t think it’s a power supply issue. This is with version 11.1 . ---
**Author:** ![abcd567](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/abcd567/32/113769_2.png) [@abcd567](https://discussions.flightaware.com/u/abcd567)\ **Post date:** [August 20, 2026, 11:02pm UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/3 "2026-08-20T23:02:29Z")
May be 978 dongle is dying? May be dump978 crashes when there are no UAT flights for a prolonged period? ---
**Author:** ![jimMerk2](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/jimmerk2/32/127232_2.png) [@jimMerk2](https://discussions.flightaware.com/u/jimMerk2)\ **Post date:** [August 20, 2026, 11:11pm UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/4 "2026-08-20T23:11:53Z")
Yeah, possibly 978 dongle going south. However, why would it start working again after a reboot? I can try another one to see what happens. If there’s no UAT flights for a period of time, the indicator goes yellow. That happens every night and many times during the day.But when there’s aircraft it goes green again. ---
**Author:** ![eaglemark](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/eaglemark/32/136865_2.png) [@eaglemark](https://discussions.flightaware.com/u/eaglemark)\ **Post date:** [August 21, 2026, 3:27am UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/5 "2026-08-21T03:27:56Z")
My 978 will fail as well while 1090 continues. I tried a different dongle in the past and still would fail. What I have been doing lately is unplug the dongle and plug it back in and and it will start working again. On my PiAware Status page the 978 indicator will be red. Fortunately the failure rate that I see is low, it will work fine for weeks . My version is 8.2. ---
**Author:** ![jimMerk2](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/jimmerk2/32/127232_2.png) [@jimMerk2](https://discussions.flightaware.com/u/jimMerk2)\ **Post date:** [August 21, 2026, 5:55am UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/6 "2026-08-21T05:55:48Z")
Ok, unplugging the dongle and replugging would be better than a reboot. Still wonder why it fails though. ---
**Author:** ![Markbone100](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/markbone100/32/135774_2.png) [@Markbone100](https://discussions.flightaware.com/u/Markbone100)\ **Post date:** [August 21, 2026, 11:29am UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/7 "2026-08-21T11:29:50Z")
Ill try that too the next time it shows red on the status screen and all the processes have stopped ---
**Author:** ![dvsvejk](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/dvsvejk/32/136416_2.png) [@dvsvejk](https://discussions.flightaware.com/u/dvsvejk)\ **Post date:** [August 21, 2026, 1:18pm UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/8 "2026-08-21T13:18:05Z")
A thought from a non-UAT feeder - maybe the USB power management/autosuspend is kicking off after a set period of time with zero UAT activity and putting the dongle to sleep. You could try disabling this feature to see if that helps. This has been posted about previously wrt Ubuntu OS. > [@Ubuntu USB autosuspend kills my 978 dongle in the winter due to no 978 pings - fix included](https://discussions.flightaware.com/t/ubuntu-usb-autosuspend-kills-my-978-dongle-in-the-winter-due-to-no-978-pings-fix-included/96490): > > Hi – I’m basically using this forum as my external memory. I’ve been noticing that in the winter my 978 dongle goes to red status (disconnected) after a certain amount of time with no pings from 978 aircraft. Due to bad weather, no 978 aircraft are flying, and after an unknown amount of time my ubuntu box shuts off the usb port it’s attached to to save power. I don’t need this feature. It’s called USB autosuspend. I googled it and this is how to turn off the USB autosuspend in Ubuntu. I ha… ---
**Author:** ![abcd567](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/abcd567/32/113769_2.png) [@abcd567](https://discussions.flightaware.com/u/abcd567)\ **Post date:** [August 21, 2026, 2:06pm UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/9 "2026-08-21T14:06:39Z")
@dvsvejk Raspberry Pi OS does not seem to have `grub` ![Screenshot_20260821_100307_Termux](https://us1.discourse-cdn.com/flex019/uploads/flightaware/original/3X/4/4/4440612e7d0000757f82c7f11ec4aad3379c8641.jpeg) ---
**Author:** ![dvsvejk](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/dvsvejk/32/136416_2.png) [@dvsvejk](https://discussions.flightaware.com/u/dvsvejk)\ **Post date:** [August 21, 2026, 2:56pm UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/10 "2026-08-21T14:56:22Z")
Correct, Raspberry Pi does not use grub like Debian(ish) systems. My assumption is the parameter goes into cmdline.txt (/boot/firmware or /boot depending on what Pi you have). ---
**Author:** ![abcd567](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/abcd567/32/113769_2.png) [@abcd567](https://discussions.flightaware.com/u/abcd567)\ **Post date:** [August 21, 2026, 2:59pm UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/11 "2026-08-21T14:59:21Z")
**QUERRY: raspberry pi os does not have grub. Which file does the function of boot loader?** ### AI Responce: On the Raspberry Pi, the boot process is entirely unique and handled by the hardware’s on-chip GPU rather than a standard x86 CPU bootloader like GRUB. The primary file that functions as the boot configuration manager—serving a similar role to how you configure GRUB—is **`config.txt`**. However, the actual process is split across several files located in the `/boot/` (or `/boot/firmware/`) partition: **1. The Main Configuration: `config.txt`** Instead of editing `/etc/default/grub`, you make all your hardware, memory, and system-level configuration changes in **`config.txt`**. This file instructs the firmware on how to boot, what overlays to load, and how to configure parameters before the Linux kernel starts. **2. The Command Line: `cmdline.txt`** This file contains the arguments passed directly to the Linux kernel upon boot. This is the exact equivalent of the `GRUB_CMDLINE_LINUX` line in a traditional GRUB setup (e.g., specifying the root partition filesystem or enabling a quiet boot). **3. The Core Firmware Execution Files** The actual binary steps that function as the stages of a bootloader include: - **On-chip ROM:** The very first stage embedded in the Raspberry Pi hardware. It wakes up the GPU and looks for the SD card/boot drive. - **`bootcode.bin`:** (On older models like Pi 3 and below) This acts as the secondary bootloader, which initializes the RAM and prepares the system. On the Raspberry Pi 4 and Pi 5, this stage is replaced by an onboard **EEPROM chip**. - **`start.elf`:** The third-stage bootloader. This is the proprietary GPU firmware that actually reads your `config.txt` parameters, sets up the hardware environment, and finally loads the Linux kernel into memory. - **`kernel8.img` or `kernel7.img`:** The actual compiled Linux kernel binary that `start.elf` hands off control to so your operating system can start up. **If you are trying to configure your system or add boot parameters, `config.txt` and `cmdline.txt` are the only two files you need to interact with.** ---
**Author:** ![abcd567](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/abcd567/32/113769_2.png) [@abcd567](https://discussions.flightaware.com/u/abcd567)\ **Post date:** [August 21, 2026, 3:32pm UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/12 "2026-08-21T15:32:49Z")
@dvsvejk ![Screenshot_20260821_110826_Termux](https://us1.discourse-cdn.com/flex019/uploads/flightaware/original/3X/2/5/25a538b9dcc2c26766bd17f7c162131ea2d050e3.jpeg) **The autosuspend by default is 2** According to **[this post](https://discussions.flightaware.com/t/ubuntu-usb-autosuspend-kills-my-978-dongle-in-the-winter-due-to-no-978-pings-fix-included/96490)**, it should be changed to **-1** ![Screenshot_20260821_112321_Termux](https://us1.discourse-cdn.com/flex019/uploads/flightaware/original/3X/9/f/9f70f8f3f12347330de92cb3bed5305c79d418ae.jpeg) ---
**Author:** ![jimMerk2](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/jimmerk2/32/127232_2.png) [@jimMerk2](https://discussions.flightaware.com/u/jimMerk2)\ **Post date:** [August 21, 2026, 5:37pm UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/13 "2026-08-21T17:37:59Z")
Thanks for looking in to this, However, when I’m in `/sys/module/usbcore/parameters` and I do `sudo nano autosuspend` it says at the bottom of the nano screen: `[Error writing lock file ./.autosuspend.swp: Permission denied]` Not sure what that means, I was not trying to write to the file, just reading it in nano. ---
**Author:** ![abcd567](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/abcd567/32/113769_2.png) [@abcd567](https://discussions.flightaware.com/u/abcd567)\ **Post date:** [August 21, 2026, 7:28pm UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/14 "2026-08-21T19:28:16Z")
> [@jimMerk2](#): > > when I’m in `/sys/module/usbcore/parameters` and I do `sudo nano autosuspend` it says at the bottom of the nano screen: > `[Error writing lock file ./.autosuspend.swp: Permission denied]` > Not sure what that means, I was not trying to write to the file, just reading it in nano. ### I asked AI, and this is what AI told me This warning happens because `/sys/` is a virtual filesystem (sysfs) created by the Linux kernel. It exists entirely in system memory, not on your storage drive, and it does not support creating standard lock files. **Why it happens** When you open a file with `nano`, it tries to create a hidden lock file (like `.autosuspend.swp`) in the same directory to prevent other users from editing it at the same time. Because the kernel filesystem is read-only for these types of metadata operations, `nano` throws a warning. **How to ignore or bypass it** - **Ignore it:** You can safely ignore this warning. Press **Enter** to dismiss it. Your changes will still save normally when you exit. - **Disable lock files:** To open the file without getting the warning, use the `-L` (or `--nolocks`) flag: **Note on permanent changes** Changes made directly to files in `/sys/` take effect immediately but **will disappear when you reboot** your Raspberry Pi. If you want to disable USB autosuspend permanently, let me know. I can show you how to add the parameter to your **boot command line** or configure a **udev rule** so it persists after a restart. ### Yes I want to disable USB autosuspend permanently, ### AI Responce To permanently disable USB autosuspend on your Raspberry Pi running **Raspberry Pi OS** , the cleanest and most reliable method is to pass a parameter directly to the Linux kernel at boot. Unlike a standard PC which uses GRUB, the Raspberry Pi reads kernel configurations from a specific text file. **Step-by-Step Instructions** 1. Open your Pi’s boot configuration file using `nano` ```auto usbcore.autosuspend=-1 ``` For example, your file should look something like this (your specific arguments may vary): ```auto console=serial0,115200 console=tty1 root=PARTUUID=... rootwait rw usbcore.autosuspend=-1 ``` 1. Save and exit `nano` by pressing **Ctrl+O** , then **Enter** , then **Ctrl+X**. 2. Reboot your Raspberry Pi for the kernel changes to take effect: **Verifying the Change** Once your Pi boots back up, check the contents of the parameter file you looked at earlier: ```auto cat /sys/module/usbcore/parameters/autosuspend ``` If the output reads **`-1`** , USB autosuspend has been permanently and globally disabled across your system. * * * If you are only trying to fix a specific problem with **one particular USB device** (like a disconnecting external drive or Wi-Fi adapter) and prefer not to disable it system-wide, let me know! I can help you write a tailored **udev rule** just for that device instead. ---
**Author:** ![jimMerk2](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/jimmerk2/32/127232_2.png) [@jimMerk2](https://discussions.flightaware.com/u/jimMerk2)\ **Post date:** [August 21, 2026, 9:10pm UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/15 "2026-08-21T21:10:57Z")
Interesting. Assuming AI knows what it’s talking about (sounds like it does), it seems ok to disable it (i.e. `autosuspend`) system-wide. The fact that it mentioned a USB WiFi adapter is also interesting. Previously I was having a problem with the RPi occasionally going belly up and completely disappearing from the client list in the WiFi router. I finally tracked that down to the USB Wi-Fi adapter. So I switched back to using the RPi internal WiFi. The reason I was using a USB WiFi adapter was that It gets a more reliable received signal on 5GHz WiFi (according to `wavemon`). However, for an ADS-B receiver. you don’t really need the data rates available on 5GHz and you get a higher received signal level at 2.4 GHz. So I forced the WiFi to stay on 2.4 GHz (using `nmcli`). But anyway getting back to the thread topic, it doesn’t seem like `autosuspend`,should be the default behavior. Edit: **Don’t follow AI instructions above for editing** **`cmdline.txt file`**. I tried it and the RPi no longer appeared in the WiFi client list. I was able to edit it back to what it was by editing the file on the Mac. However, now `dump1090-fa` and `dump978-fa` services no longer seem to run. Have to figure that out. ---
**Author:** ![abcd567](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/abcd567/32/113769_2.png) [@abcd567](https://discussions.flightaware.com/u/abcd567)\ **Post date:** [August 22, 2026, 12:23am UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/16 "2026-08-22T00:23:15Z")
> [@jimMerk2](#): > > Edit: **Don’t follow AI instructions above for editing** **`cmdline.txt file`**. I tried it and the RPi no longer appeared in the WiFi client list. I was able to edit it back to what it was by editing the file on the Mac. However, now `dump1090-fa` and `dump978-fa` services no longer seem to run. Have to figure that out. Very strange. **Before posting AI responce above** , I tested the method by doing the modification in cmdline.txt exactly as suggested by AI, and rebooted RPi. After Reboot, I could SSH to RPi using same local IP address. After reboot I gave following command and its output showed it is set to `-1` `cat /sys/module/usbcore/parameters/autosuspend` ---
**Author:** ![jimMerk2](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/jimmerk2/32/127232_2.png) [@jimMerk2](https://discussions.flightaware.com/u/jimMerk2)\ **Post date:** [August 22, 2026, 2:03am UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/17 "2026-08-22T02:03:17Z")
Yeah, it sounds like it should work. When I edited `cmdline.txt` back to the original, I checked to see that there was no return character in the file like the AI instructions said, and there was none. I didn’t check for a typo, but we will never know now. Regarding the services for `dump1090-fa` and `dump978-fa` that appeared not to be running at first, they were running. However they weren’t the modified service files I usually use (that turn on the biast). Don’t know why that happened either. ---
**Author:** ![abcd567](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/abcd567/32/113769_2.png) [@abcd567](https://discussions.flightaware.com/u/abcd567)\ **Post date:** [August 22, 2026, 2:34am UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/18 "2026-08-22T02:34:22Z")
> [@jimMerk2](#): > > I didn’t check for a typo, but we will never know now. Most likely it was a typo. I dont see any other reason   > [@jimMerk2](#): > > they weren’t the modified service files I usually use (that turn on the biast). Don’t know why that happened either. Possibly an update replaced your modified service file by the default one. To prevent this to happen again on every update, don’t modify the service file itself. Instead add a drop-in file withe necessary modifications. The drop-in file does not get modified or removed by an update / upgrade. ## This is how to create a drop-in ### (1) Compile binary rtl\_biast from source code Do **NOT** build rtl\_biast binary in `/home/pi/` as dump1090-fa service fails to use it, although the binary rtl\_biast is executable.(`-rwxr-xr-x`). `Process: 159174 ExecStartPre=/home/pi/rtl_biast/build/src/rtl_biast -b 1 (code=exited, status=203/EXEC)` **Following method builds the binary `rtl_biast` in folder `/usr/share/rtl-biast` where dump1090-fa service can access it** ```auto sudo git clone https://github.com/rtlsdrblog/rtl_biast /usr/share/rtl-biast cd /usr/share/rtl-biast sudo mkdir build cd build sudo cmake .. -DDETACH_KERNEL_DRIVER=ON sudo make ``` ### (2) Create service drop-in ```auto sudo mkdir -p /lib/systemd/system/dump1090-fa.service.d sudo nano /lib/systemd/system/dump1090-fa.service.d/bias-t.conf ``` In above newly created blank file `bias-t.conf`, copy-paste following lines ```auto [Service] ExecStartPre=/usr/share/rtl-biast/build/src/rtl_biast -b 1 ``` Save file and restart dump1090-fa. ```auto sudo systemctl daemon-reload sudo systemctl restart dump1090-fa ```   _ **Click on Screenshot to See Larger Size** _ ![image](https://us1.discourse-cdn.com/flex019/uploads/flightaware/original/3X/9/d/9ded14f4a4d201de6664a8bb5458054515ec6507.png)   ---
**Author:** ![jimMerk2](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/jimmerk2/32/127232_2.png) [@jimMerk2](https://discussions.flightaware.com/u/jimMerk2)\ **Post date:** [August 22, 2026, 3:23am UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/19 "2026-08-22T03:23:13Z")
Thanks for the tip about not modifying the service files themselves. I’ll try that. Back on the `cmdlne.txt` file. I was looking at Raspberry Pi forums, and the way AI says to make the change is correct. So the mystery remains on that. ---
**Author:** ![jimMerk2](https://sea1.discourse-cdn.com/flex019/user_avatar/discussions.flightaware.com/jimmerk2/32/127232_2.png) [@jimMerk2](https://discussions.flightaware.com/u/jimMerk2)\ **Post date:** [August 22, 2026, 8:10am UTC](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674/20 "2026-08-22T08:10:04Z")
Ok, I again edited the `cmdline.txt` file to disable `autosuspend` and then rebooted and this time it worked! So now we will see if this fixes the occasional stopping of `dump978-fa`. [Next page](https://discussions.flightaware.com/t/piaware-keeps-crashing/100674.md?page=2)