BlueZ bus interface is not cached and can not be cleaned up properly
See original GitHub issue- bleak version: 0.5.1
- Python version: 3.5
- Operating System: osmc
- BlueZ version (
bluetoothctl -v
) in case of Linux: 5.43
Description
Repeated calls to client.connect()
(both on the same instance, as well as newly created instances) will create new bus-objects (see client.py:96) for each call, without the means to clean them up again.
What I Did
Auto-Reconnect loop like this:
while True:
client = bleak.BleakClient(addr, loop=loop)
try:
await client.connect()
except bleak.exc.BleakError as exc:
logging.error('failed to connect: %s', exc)
continue
[... logic here ....]
What I expected
Either client.__del__
or an explicit client.cleanup
to call client._bus.disconnect
, or client._bus
to be cached.
What happened
WARNING failed to connect: org.bluez.Error.Failed: Software caused connection abort
[previous message repeats 244 times]
Traceback (most recent call last):
File "/usr/local/sbin/ble.py", line 156, in reconnect
await client.connect()
File "/opt/bleak-venv/lib/python3.5/site-packages/bleak/backends/bluezdbus/client.py", line 93, in connect
await discover(timeout=timeout, device=self.device, loop=self.loop)
File "/opt/bleak-venv/lib/python3.5/site-packages/bleak/backends/bluezdbus/discovery.py", line 128, in discover
bus = await client.connect(reactor, "system").asFuture(loop)
File "/usr/lib/python3.5/asyncio/futures.py", line 380, in __iter__
yield self # This tells Task to wait for completion.
File "/usr/lib/python3.5/asyncio/tasks.py", line 304, in _wakeup
future.result()
File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result
raise self._exception
txdbus.error.RemoteError: org.freedesktop.DBus.Error.LimitsExceeded: The maximum number of active connections for UID 0 has been reached
Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:6 (3 by maintainers)
Top Results From Across the Web
BlueZ showing old cached data on DBUS - Stack Overflow
As it turned out, BlueZ is indeed keeping Bluetooth devices cache. It can be found in. /var/lib/blueooth. in folders named by MAC addresses....
Read more >Bluetooth - ArchWiki
To do this, first pair your device on your Arch Linux install. Then reboot into the other OS and pair the device. Now...
Read more >Unable to access a BrightSign at that ip address - LS423
Hi, I've been trying to "reach" my LS423 for over a week now, here is what I've done to test so far: 1-...
Read more >D-Bus and Bluez - ukBaz Notes
These BlueZ APIs use D-Bus which is not widely known about so this article aims to give some background to help people get...
Read more >How to Fix Bluetooth Pairing Problems - Techlicious
Bluetooth Smart devices are not backward compatible and won't recognize ... With phones, an easy way to do this is by going into...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Just saw the comments on the PR as well as issue #169. I think this is adressed by PR #154. Thanks.
I had the chance to test this only now. Unfortunately, this issue was only shifted to a different place. The AsyncioSelectorReactor creates a new pipe for each instance, which is never cleaned up. Simple script to see the issue:
And no, spinning up and stopping the reactor doesn’t help:
My system has a
ulimit -d
setting of 1024, so as soon as 102x-something connect() calls were performed, my application will crash.(I do understand that I need to raise this issue with the twisted team - I’m just documenting this here for the record.)