[systemd-devel] powering on bluetooth after suspend - required services aren't ready

[lukash]

Hi Marcel,

thank you for the exhaustive information :)

On Sat, 2015-09-26 at 19:49 +0200, Marcel Holtmann wrote:
> Hi Lukas,
> 
> > When a system wakes from suspend, the Bluetooth adapter needs to be
> > explicitly powered on. This can be conveniently done by a systemd
> > service file, as described for example on Archlinux wiki [1] (the
> > systemd service file at the bottom of the section).
> > 
> > The hciconfig binary used to work up to kernel 4.1.5, with 4.1.6 and up
> > it stops working with Bluetooth LE (4.0) devices. The tool is
> > deprecated, instead a dbus call (ie. the commented line in the systemd
> > service file in [1]) or another tool, btmgmt, can be used to power on
> > the Bluetooth adapter.
> > 
> > The problem is neither of these tools work at the time systemd invokes
> > them, they require the bluetooth daemon to reinitialize itself after
> > resume (at least for the dbus call it needs to listen on dbus, not sure
> > about the btmgmt tool). Normally systemd handles this gracefully, but
> > after resume, the required services appear ready to systemd while they
> > aren't.
> > 
> > What is the proper solution to this problem?
> 
> anybody hacking in a tool that manually powers on the previously
> powered Bluetooth controller is doing something wrong. The question
> that should have been asked is why the controller got powered down in
> the first place.
> 
> An obvious issue could be that for some reason the device
> manufacturer decided to pull the power on the Bluetooth controller
> (aka USB disconnect) instead of handling proper suspend/resume. The
> btusb driver for example does support suspend/resume correctly, but
> it can not do anything about stupid devices. If they physically
> disappear from the bus, then they are for all intense and purposes
> unplugged.

Well, are there Bluetooth adapters that actually behave like this? I'm
just trying to make my Bluetooth work and what they say on the internet
(mainly the Arch wiki) is to power the adapter on at boot and on resume
from suspend. Not much more I can do about it.

> Now for the lifetime of bluetoothd, it could remember the state of
> such a controller and restore it when it comes back. However that
> does not really help us sine we actually want to stop bluetoothd when
> no Bluetooth hardware is attached to the system. So that means that
> bluetoothd would have to store the value persistently over restarts.
> Which now is a problem since we need to account for the overall
> offline mode policy. That offline mode policy is not well defined
> (unless you run something like ConnMan) and so the only safe bet is
> to initialize the controller, but not power it on.
> 
> Just for reference, hciconfig has been deprecated since a long time
> now. It is a nice tool for quick and dirty testing, but using in
> production systems to power on a controller will not make your life
> happy. Especially if you want to use Bluetooth 4.0 Low Energy (LE)
> feature. The btmgmt is for developers and testers of the kernel API
> and is not even installed by BlueZ upstream package.
> 
> The correct way is indeed to use bluetoothctl or send a D-Bus
> message. Something that can be done easily by the Bluetooth UI that
> also provides the Bluetooth agent. The UI will most likely have a
> good idea about the offline policy and can nicely enforce it.

I am not exactly sure what you mean by Bluetooth UI if it's anything
else than bluetoothctl, which I use. But it doesn't provide persistent
power state handling. And I obviously want my Bluetooth to be turned on
automatically, not to have to turn it on myself each time.

So, AFAICT bluez doesn't provide me with means to persistently store
the adapter power state and without the developer tools (hciconfig and
btmgmt) to even turn it on programmatically, except for the manually
crafted dbus message? With the problem that after suspend the
bluetoothd doesn't immediately listen on dbus, therefore without added
synchronization this method is not reliable?

I've just done some looking around and noticed you've actually been
discussing this issue on the bluez mailing list. So (even though it's
getting OT here), is there a working solution for this issue using
bluez?

If not, perhaps there could still be a way to activate the oneshot
systemd service after suspend and only when bluetoothd is listening on
dbus to workaround the bluez issue?

Cheers,
Lukas