org.bluez.Adapter1: StopDiscovery: Error: Operation already in progress #80
Assignees
Labels
bug
Something isn't working
Comments
|
@alzuno I'd seen some problems like this but was hoping that I'd fixed it. Are you running on a Raspberry Pi or another platform? (I'm guessing by your machine name in the logs that it's a Raspberry Pi3.) Is the software running as the user goveebttemplogger instead of root? (one of my recent changes was to avoid running as root) Are you running anything else that uses Bluetooth? (Keyboard, Mouse, or any other program?) Am I correct that the Bluetooth appears to not work at all after this problem occurs, and the only way to recover it is to reboot the entire machine? I've seen this issue and am not sure what's happening. There may be something I'm not cleaning up in the DBus communication that is causing BlueZ to leak memory and stop responding. It seems wrong that a user mode program can crash a piece of system software.. You should be able to revert to the old hardware Bluetooth Hardware Control Interface by adding the --HCI option to the end of the command line, but that probably won't recover the Bluetooth after it's locked up. Using HCI took exclusive control of the Bluetooth interface and has been deprecated for several years. |
|
@alzuno Commits I made today c8e2cd1 and then 6b895c5 bring the version up to 3.20241115.1 and I'm hoping will squash the issue you have for good. I'm going to run this on my primary machines for a couple of days before creating a new release, but I'm interested if this fixes the issue on your platform. |
|
Hi @wcbonner, Thanks for your reply, and sorry for the delayed response (I’m on the "other side of the pond").
Yes, it's a Raspberry Pi3: And here’s the OS information:
It is running as the
No, it’s a headless setup. Nothing but electricity is connected to the Raspberry Pi, and no other program is using Bluetooth.
Yes, that’s exactly the behavior. The only way to recover is to reboot the machine.
Great! I’m updating to the latest version now and will run it over the weekend. I’ll let you know the results. |
|
Hi @wcbonner, I updated the system to 3.20241115.1 version, and unfortunately it seems is not working. Here's a journalctl output: And here's running on console with verbose 1: Please let me know if you need anything else from me. |
|
@alzuno I'm not sure why it's not working for you. My test would be to disable the service and reboot the machine. preferably power cycled, but sometimes doing that on a headless machine is a pain. then at the command line run these commands, replacing "wim" with the name of your local logged in user. I made a minor change this morning, bumping the version to 3.20241116.0 but it shouldn't have changed the main logic. Run the program in default DBus mode. If it reports govee devices and temperatures, that's good. If not, I'm interested if you let it run for over half an hour if it closes the DBus connection and opens another with a different name successfully. If the DBus communication didn't work, try the same by adding the --HCI option to see if it gets data that way. |
|
Hi @wcbonner,
After this, I updated the system and rebooted it again. It's now been running for approximately 24 hours without any problems. I'm not sure what was causing the previous issues, but for now, everything seems to be working correctly. I'll continue monitoring and will let you know if the issue reappears. Thank you so much for your help! Let me know if there’s anything else you’d like me to test. |
|
Additionally, in the running service logs, I’ve noticed that every 30 minutes the system closes a D-Bus connection and opens a new one with a different code. Here’s a snippet from the logs: |
@alzuno Glad to know that it seems to be working properly now. I still don't know what could have been causing the problems you saw. The changes I made should make things more robust long term. I imaged a I'm going to close this issue. If it recurs, please reopen it instead of creating a new one. |
|
Hi @wcbonner, This morning, I noticed the system exhibiting the same behavior as before. While it appears to be running longer than it did previously, it’s still encountering the Error: Operation already in progress. Let me know if you’d like to add more details or logs! P.S: I will try adding the --HCI option to see if it gets data that way and doesn't halt. |
|
@alzuno Can you remind me of your exact system: Also check the logs if there are any bluetooth messages interspersed with the goveebttemplogger messages? On my Pi Zero I get a bunch of bluetooth messages as the system boots but then it recovers and works as I expect. I updated a bit more error checking yesterday so updating your cade may be helpful. |
|
Thanks @wcbonner
I will update and let you know the results after that. |
|
After updating to version I modified the service to include the Please let me know if there's anything else I can assist with. Thank you. |
|
@alzuno I added a bunch more error logging logic with the 3.20241120.0 code commit today, but since I still can't figure out why your system is freezing, I don't know if it will improve it at all. One thing I added was that I explicitly remove the match rules from the DBus connection before I close it. I was not doing that previously, and don't know if it may have been causing DBus to run out of resources. I hope that the --HCI option is continuing to run properly for you. I've also done some cleanup in the past week to have the --HCI code use the exact same decode routines as the DBus code. There had been a few thermometer types I'd added since I stopped doing the HCI development, and it was easier to remove the old code than maintain duplicate routines. I may try to get my hands on a Raspberry Pi 3 Model B Plus over the holidays that I can run buster on and see if I can duplicate your issue. The Pi4 I have running Buster isn't exhibiting the problem, but my Pi4 and Pi5 have more ram, which may contribute to the problem. You said you are running headless, are you running the OS without running the GUI at all? or are you set to be able to VNC in and use the GUI on occasion? |
|
Hi @wcbonner, I updated to version Adding the I'm running Raspberry Pi OS Lite (no GUI) on a Raspberry Pi 3. Thanks! I'll keep it running with |
|
@alzuno If you want to try one more test, after it starts producing the error run the command: I'm interested in what it thinks is going on with bluetooth. And then try running before resorting to a full reboot. |
|
I mistakenly asked for a buster build on the Pi3. It looks like my code automatically reverted to using the HCI interface on that platform. I rebooted to make sure it wsn't something related to my initial testing before I installed the package: I'll see if I can get the system rebuilt with bullseye over the weekend. |
|
Hi @wcbonner, I’ve completed the testing you requested, and I can confirm that restarting the Bluetooth service resolved the issue. Here are the details: Bluetooth Status Before Restart Bluetooth Service Restart After restarting the Bluetooth service, the system returned to normal operation. Log with the system working again after the reboot from the bluetooth service: I hope this information will be useful to you. About the buster build reverting to use the HCI interface, it seems not to be the same on bullseye. As you can see in the logs if i don't use the --HCI option, the system uses Bluez. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi @wcbonner,
I've been experiencing recurring service interruptions. Over the past month, the system hasn't remained up for more than 24 hours. Previously, it would sometimes run for a month without any issues.
From the logs, I noticed this recurring error:
/org/bluez/hci0: org.bluez.Adapter1: StopDiscovery: Error: Operation already in progress /home/pi/GoveeBTTempLogger/goveebttemplogger.cpp(3918)After this error appears, the logging stops entirely. The only way to get the system working again is to reboot the Raspberry Pi.
Here a piece of logs from the system:
I ran the system on the console and observed the same issue:
Additional Information:
Thanks for your help!
The text was updated successfully, but these errors were encountered: