Piaware keeps crashing

FlightAware ADS-B Flight Tracking
1

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.

2

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 .

3

May be 978 dongle is dying?

May be dump978 crashes when there are no UAT flights for a prolonged period?

4

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.

5

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.

6

Ok, unplugging the dongle and replugging would be better than a reboot. Still wonder why it fails though.

7

Ill try that too the next time it shows red on the status screen and all the processes have stopped

8

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.

9

@dvsvejk

Raspberry Pi OS does not seem to have grub

Screenshot_20260821_100307_Termux
Screenshot_20260821_100307_Termux1079×444 152 KB

10

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).

11

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.

12

@dvsvejk

Screenshot_20260821_110826_Termux
Screenshot_20260821_110826_Termux1080×622 173 KB

The autosuspend by default is 2
According to this post, it should be changed to -1

Screenshot_20260821_112321_Termux
Screenshot_20260821_112321_Termux1028×208 42.9 KB

13

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.

14

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:

    sudo nano -L /sys/module/usbcore/parameters/autosuspend

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

    sudo nano /boot/firmware/cmdline.txt

    The file will contain a single line of text with various configuration settings separated by spaces. Do not add a new line. Scroll to the very end of that single line, add a space, and append the following parameter:

   usbcore.autosuspend=-1

For example, your file should look something like this (your specific arguments may vary):

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:

    sudo reboot

Verifying the Change

Once your Pi boots back up, check the contents of the parameter file you looked at earlier:

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.

15

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.

16

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

17

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.

18

Most likely it was a typo. I dont see any other reason

 

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

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

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

[Service]
ExecStartPre=/usr/share/rtl-biast/build/src/rtl_biast  -b 1

Save file and restart dump1090-fa.

sudo systemctl daemon-reload
sudo systemctl restart dump1090-fa

 

Click on Screenshot to See Larger Size

image
image1135×512 75.2 KB

 

19

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.

20

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.