write_gatt_char fails when called in systemd service

[dreadnought]

• bleak version: 0.11.0
• Python version: 3.6.9
• Operating System: Ubuntu 18.04
• BlueZ version (bluetoothctl -v) in case of Linux: 5.48

Description

I've written an application and it works fine when I start it from the shell, but when I start it as a systemd service, write_gatt_char fails and reports OSError: [Errno 9] Bad file descriptor. In both cases the program runs as root user. The systemd service file doesn't set any restrictions, but I can imagine that systemd might try to isolate the process in a way that bleak doesn't expect. I didn't find any reports of similar issues related to systemd and D-Bus, so I'm wondering what the can be or how I can debug it further.

What I Did

I've striped the code down to this example:

#!/usr/bin/python3
import asyncio
from bleak import BleakClient

address = "AA:BB:CC:DD:EE:FF"

async def run(address):
    print("Connecting")
    async with BleakClient(address) as client:
        print("Reading")
        await client.read_gatt_char(17)
        print("Writing")
        await client.write_gatt_char(48, bytearray(b""))
        print("Done")

print("Start")
loop = asyncio.get_event_loop()
loop.run_until_complete(run(address))
print("End")

Running it as root user from the shell gives this output:

# ./bleak_example.py 
Start
Connecting
Reading
Writing
Done
End

Then I have a Systemd service file that looks like this:

[Unit]
Description=Example Service
After=bluetooth.target time-sync.target

[Service]
Type=simple
ExecStart=/root/bleak_example.py
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

And after starting the service, it writes the following lines to the journal:

Apr 28 17:29:39 dev systemd[1]: Started Example Service.
Apr 28 17:29:48 dev bleak_example.py[24099]: Start
Apr 28 17:29:48 dev bleak_example.py[24099]: Connecting
Apr 28 17:29:48 dev bleak_example.py[24099]: Reading
Apr 28 17:29:48 dev bleak_example.py[24099]: Writing
Apr 28 17:29:48 dev bleak_example.py[24099]: Traceback (most recent call last):
Apr 28 17:29:48 dev bleak_example.py[24099]:   File "/root/bleak_example.py", line 18, in <module>
Apr 28 17:29:48 dev bleak_example.py[24099]:     loop.run_until_complete(run(address))
Apr 28 17:29:48 dev bleak_example.py[24099]:   File "/usr/lib/python3.6/asyncio/base_events.py", line 484, in run_until_complete
Apr 28 17:29:48 dev bleak_example.py[24099]:     return future.result()
Apr 28 17:29:48 dev bleak_example.py[24099]:   File "/root/bleak_example.py", line 13, in run
Apr 28 17:29:48 dev bleak_example.py[24099]:     await client.write_gatt_char(48, bytearray(b""))
Apr 28 17:29:48 dev bleak_example.py[24099]:   File "/usr/local/lib/python3.6/dist-packages/bleak/backends/bluezdbus/client.py", line 815, in write_gatt_char
Apr 28 17:29:48 dev bleak_example.py[24099]:     os.write(fd, data)
Apr 28 17:29:48 dev bleak_example.py[24099]: OSError: [Errno 9] Bad file descriptor
Apr 28 17:29:48 dev systemd[1]: example.service: Main process exited, code=exited, status=1/FAILURE
Apr 28 17:29:48 dev systemd[1]: example.service: Failed with result 'exit-code'.

[dlech]

I would suggest creating a utility user account that is a member of the bluetooth group and run the systemd service as this user.

Also, a newer BlueZ version would avoid the code path that calls os.write().

[dreadnought]

Thanks for the quick response. Updating BlueZ from 5.48 to 5.53 solves the issue. There are no more recent OS versions for my single board computer than Ubuntu 18.04, so I took the bluez package from the Ubuntu 20.04 repository and installed it manually. After that it works as expected.

I agree that it makes sense to run it with different user than root, but I thought that if it fails with root, a user with lower privileges will make it better.

[devanlai]

Adding a note that I encountered this issue (using BlueZ 5.50, which is the latest in Debian stable). Running as a non-root user, the behavior I see is that the fd is zero, so it writes the GATT value to stdout instead of sending it to whatever socket is actually meant to receive the GATT write.

Avoiding the AcquireWrite code path by setting response=True also works (with a performance penalty), and I'm guessing that upgrading to a newer version of BlueZ by installing a backport would also work for me.

I'm wondering if there's some sort of weird dbus issue that causes it to respond with invalid file descriptors like we see in this issue and per es617's comment on #525.

[dlech]

We didn't realize it when we switched to dbus-next, but that library only has experimental support for passing unix file descriptors via dbus, so there is probably some bug in that library.

[devanlai]

That's unfortunate that dbus-next doesn't play nice with the file descriptors, though I'm beginning to lean towards the view that it's just not worth the hassle to try to work with older versions of BlueZ since BlueZ 5.50 has some other bugs like UUID scan filtering not working.