Async read stalled? After weeks of running. How to fix?

[MatejsLab]

Hi,

I am running the rtl_433 on two linux pepermint home servers for a year now, i really like it (when working).

Last few months the issues arised that is stops working and needs manual restart of service, odd right.

The rtl_433 randomly stops working after many weeks of normal runitime, it keeps reocouring lately.

Below is the status data, but how do i fix it so it doesn't stall . Or how it should decide to restart? As service doesn't detect error to restart.

For reference i have one blue and one black RTL stick from Aliexpress. Blue has better range, but both work fine in near proximity of temperature sensors and rain sensors.

I forgot if i wrote the service or it was installed?
I compiled it and it is 1 year ago so i barely remember what i did, and so it is harder to fix.

Help Appriciated,

Matej

rtl_433 
version nightly-10-g07368e73 branch master at 202309251404 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/serveroh2/.config/rtl_433/rtl_433.conf"...
Reading conf from "/home/serveroh2/.config/rtl_433/rtl_433.conf".
[Protocols] Registered 211 out of 246 device decoding protocols [ 1-4 8 10-12 15-17 19-23 25-26 29-36 38-45 47-60 63 67-71 73-100 102-105 108-116 119-121 124-128 130-149 151-161 163-168 170-175 177-197 199-215 217-228 230-232 234-237 239-241 243-244 246 ]
usb_claim_interface error -6
[sdr_open_rtl] Failed to open rtlsdr device #0.
[sdr_open_rtl] Unable to open a device


service rtl_433 status
● rtl_433.service - <rtl_433_MQTT_MK>
   Loaded: loaded (/etc/systemd/system/rtl_433.service; enabled; vendor preset: enable
   Active: active (running) since Mon 2024-08-12 21:57:46 CEST; 1 months 7 days ago
 Main PID: 1488 (rtl_433)
    Tasks: 3 (limit: 4618)
   CGroup: /system.slice/rtl_433.service
           └─1488 rtl_433 -F mqtt://192.168.1.100 1883 retain 0 devices senzorji_RTL_4

sep 17 22:45:11 serveroh2 bash[1488]: Temperature: 23.20 C
sep 17 22:45:11 serveroh2 bash[1488]: Humidity  : 62 %
sep 17 22:45:11 serveroh2 bash[1488]: Modulation: ASK
sep 17 22:45:11 serveroh2 bash[1488]: Freq      : 433.9 MHz
sep 17 22:45:11 serveroh2 bash[1488]: RSSI      : -9.4 dB
sep 17 22:45:11 serveroh2 bash[1488]: SNR       : 18.1 dB
sep 17 22:45:11 serveroh2 bash[1488]: Noise     : -27.5 dB
sep 17 22:45:20 serveroh2 bash[1488]: [Auto Level] Current noise level -28.7 dB, estim
sep 17 22:45:30 serveroh2 bash[1488]: [Auto Level] Current noise level -28.9 dB, estim
sep 17 22:45:54 serveroh2 bash[1488]: [Input] Async read stalled, exiting!

[zuckschwerdt]

"Async read stalled, exiting!" suggests a hardware failure. The problem is that the RTL-SDR stops sending data -- it is likely locked-up / frozen. That's what the "usb_claim_interface error" also suggests -- the RTL-SDR is not available.

I had this happen with these causes: bad power supply (aging it would undervolt), overheated RTL-SDR (random freezes, days or weeks apart).

[ProfBoc75]

"Async read stalled, exiting!" suggests a hardware failure. The problem is that the RTL-SDR stops sending data -- it is likely locked-up / frozen. That's what the "usb_claim_interface error" also suggests -- the RTL-SDR is not available.

I had this happen with these causes: bad power supply (aging it would undervolt), overheated RTL-SDR (random freezes, days or weeks apart).

Agree, I was also facing such issues due to bad contacts. My advice is to have a good quality usb extension cable, tighten connectors to force contacts, the USB A ground part of the RTL dongle.

[MatejsLab]

Oh I understand, the dongle may be glitching.

• I have it straight in the USB of the mini PCs, and i feel that it has tight connection.
• PSU seems fine, mini PC at home has 5.0V on USB and 12.4V on supply, it is 1y old, shouldn't be bad right.
• What case temerature would be counted as overheating, they have around 38°C on USB case.
• It was working fine for a year.

I would like to make quick patch to eliminate manual service restarts.

Where do i find code that handles the connection to USB so i can add a log and return code and to trigger service restart?
Well eventually i can also monitor MQTT and trigger a service restart, if need be.

The thing thats strange is that both dongles have issues recently, even tho they are on diferent geo location and mini PCs are on UPS.

The odd thing is that is starts up fine after service restart, but not by itself?
Yesterday i restarted both rtl_433 services for local black dongle and on remote pc for blue dongle.
As far as i see the blue keeps working for longer, but both worked for a year without issues, that arised lately, hmm?

I mean, not sure what to improve on hardware, but i would like to improve software to acomodate for one glich a month and restart by itself.
Is there a way to detect error and do return code so the service restarts, as service is unaware of the issue now and it keeps waiting on active.

I supose that if it were locking up every few minutes or hours it is bad hardware, otherwise it should restart by itself, right.

[zuckschwerdt]

Current versions of rtl_433 support controlling restart/exit on device failure:

  [-D restart | pause | quit | manual] Input device run mode options.

It's not well tested (lacking broken hardware) but should work. Older versions might just get stuck on device problems.

[ProfBoc75]

I have it straight in the USB of the mini PCs, and i feel that it has tight connection.

We recommend using an USB extension cable to improve the reception. To be as far as possible from the rf noise generated by the PC / mini PC/ SBC. It could work directly from the USB port like you did, but not the best solution.

[MatejsLab]

Great, i will experiment with both solutions, thanks. V pet., 20. sep. 2024, 17:59 je oseba Bruno OCTAU ***@***.***> napisala:

…

I have it straight in the USB of the mini PCs, and i feel that it has tight connection. We recommend using an USB extension cable to improve the reception. To be as far as possible from the rf noise generated by the PC / mini PC/ SBC. It could work directly from the USB port like you did, but not the best solution. — Reply to this email directly, view it on GitHub <#3057 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG3CQWPNF45NOI3POWK2KL3ZXRA6XAVCNFSM6AAAAABOQ2FO22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRUGA2DSMBSGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[MatejsLab]

Hi, i pluged the USB RTL into 30cm usb extension and also i apended the -D restart option into the start command. For now it seems more stable, no issues the last day. Thanks for recomendations, I will report after some time, hopefully the reliability improved. V pet., 20. sep. 2024, 19:06 je oseba Matej Kotnik ***@***.***> napisala:

…

Great, i will experiment with both solutions, thanks. V pet., 20. sep. 2024, 17:59 je oseba Bruno OCTAU < ***@***.***> napisala: > I have it straight in the USB of the mini PCs, and i feel that it has > tight connection. > > We recommend using an USB extension cable to improve the reception. To be > as far as possible from the rf noise generated by the PC / mini PC/ SBC. It > could work directly from the USB port like you did, but not the best > solution. > > — > Reply to this email directly, view it on GitHub > <#3057 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AG3CQWPNF45NOI3POWK2KL3ZXRA6XAVCNFSM6AAAAABOQ2FO22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRUGA2DSMBSGU> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >