-
Notifications
You must be signed in to change notification settings - Fork 491
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bluepy-helper locking cpu on debian 9 when in a vm on proxmox #239
Comments
Same issue under ubuntu 16.04 and docker python:3.6 (Debian 8), for home-assistant and magicblue plugin . The bluepy-helper gets stuck at %100 CPU usage. As a workaround till this gets fixed, the helper can be killed with the monit service using this configuration:
The parent python process will restart it .
As you can see the thing hangs randomly every few hours. |
I'm getting this same bug (or something that very much looks like it) on debian stretch on a Raspberry pi. Bluepy1.1.4. No virtualization. Happens maybe once per day. I'm pretty sure I saw the same issue back on Jessie. I used to solve it by automatically bouncing my whole app and letting upstart bring me back. But this seems at least 50% less icky, while still being a hideous solution. |
Except that it didn't quite work longer-term -- around 12 hours later, I get the error "An error occurred: Error from Bluetooth stack (badstate)" after a while, even after killing and restarting bluepy-helper. And this error didn't have the telltale 100% CPU on bluepy-helper. |
Same problem on Debian 9.4 and ESXi 6.5 U2. @alexsarmiento in my case monit didn't works. |
I have the same problem on raspberry pi. After a while (around 1 day) the system has a lot of bluepy-helper processes in state D (uninterruptible sleep), which I cannot kill: root 32545 0.0 0.0 3644 696 ? D 18:11 0:00 /usr/local/lib/python2.7/dist-packages/bluepy/bluepy-helper The only way I found is to reboot the raspberry pi. Is there a fix for this issue? |
Same problem 100% CPU on bluepy-helper on debian9 4.9.0-6-amd64 ... unusable for me |
Same problem here, on debian9 and ESXi 6.7
|
I have just made a 1.2.0 release of Bluepy which has updated the underlying Bluez sources to 5.47, which has a lot of bugs fixed since the original 5.29. It would be useful to know if this changes the behaviour in any way. |
Thanks, the issue is still there with v1.2.0 |
I still have the bluepy-helper randomly just die midstream with 1.2.0/5.47, and it happens considerably more frequently than it used to. I don't see anything obvious in daemon.log-- is there anywhere else I should look? I haven't seen the case where it goes to 100% CPU yet, though, but it's only been a day. Bluez is up to 5.50 now, although I don't see anything that looks like a related bug. Any ideas on how to debug, or what would make bluepy-helper unexpectedly disappear? |
I'm getting this on Ubuntu 18.04 with a UD100 device running in Docker. and it works fine for a few days, then after that it stops responding (I have a lock so only one thread can run bluetooth commands at once, which is causing a deadlock). running
Any help would be appreciated. |
I discovered that the issue for me was the peripheral application was throwing an exception and failing to return a response for the write (it has withResponse=True set). I think this is a bug in |
+1 seeing this error running on rpi 4 with home assistant in a virtual env. Have the latest versions of bluez and bluepy. See similar behaviour as @DylanSale |
Bugfix of high CPU usage After the BLE Connection is established, a L2CAP socket will be added the GLib
hereby is the patch to fix |
@xsun1213 it seems it was not merged until today, right? Thanks, |
@IanHarvey it seems the patch above has been "approved" by multiple people. Do you think it could benefit from a new release :) ? There is no breaking change as far as I know. It would be great! Thank you for your work, |
Looks like the patch was merged in 8818eb2 |
Hi,
Running debian9 in a vm, we are several people from the jeedom community having a problem with our vm crashing/locking randomly after a certain amount of time (seems random).
The VM suddenly have one of its core used at 100% by a process, then seems to die.
Looking into the the kern.log, we see that the culprit seems to be pluepy-helper locking the cpu.
Nov 23 03:13:16 jeedom-debian9-bluetooth kernel: [13228.136257] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [bluepy-helper:5618]
Nov 23 03:13:16 jeedom-debian9-bluetooth kernel: [13228.136294] CPU: 2 PID: 5618 Comm: bluepy-helper Tainted: G L 4.9.0-4-amd64 #1 Debian 4.9.51-1
I got 3 hours of this then nothing. Myu guess is that after 3 hours the VM died.
Strangely enough, this does not happen with debian 8.
The text was updated successfully, but these errors were encountered: