[SOLVED] Activate bluetooth controller on boot

Question

I've recently finished setting up my computer for server and htpc use. Everything is working fine except bluetooth support. As of now, bluetooth pairing, connection and auto-connection is working fine, as soon as the adapter has been turned on (by user intervention over ssh). For some odd reason though, the bluetooth adapter is always turned off on boot. I have bluez 5.7 and bluez-utils installed; therefore I can either do
bluetoothctl
bluetooth> power on
via ssh, or
hciconfig hci0 up
After turning bluetooth on with these commands, everything is working fine. I couldn't manage to autorun these commands on boot (with root permissions). Already tried to write a service file, which didn't work. I also kinda got it semi-working with connman installed and autostarted at boot. The problem with connman is, that it correctly activates the controller on boot, but does then go to sleep / power saving mode after some time and also gives me some errors (which are irrelevant for this issue, but still not good) in /var/log/errors.log. So, I just uninstalled connman, because it has no use for me and I want to keep everything as simple and lightweight as possible. I already have all the tools to start up, pair and connect my bluetooth devices, I just need a way to run the commands above at boot.
rfkill list
tells me, that everything is unblocked. The controller itself is recognized with "lsusb" command, but the link is down at boottime (via "hciconfig" command). Is a udev rule an option for this kind of task or do I need to write a service file (in which I failed until now)?
Any help is welcome!
Last edited by tolga9009 (2013-07-07 22:11:33)

Answer 1

You may as well try _native_ method of bluez5 via dbus, something like
dbus-send --system --type=method_call --print-reply=literal --dest=org.bluez /org/bluez/hci0 org.freedesktop.DBus.Properties.Set string:org.bluez.Adapter1 string:Powered variant:boolean:true
It doesn't really mater how you will synchronize it but most proper way I think would have been through systemd, since udev reacts to hardware interface (i.e. rfkill enabled hardware and kernel layer created interface) while it is bluetoothd who is expected to make all the proper initialization. But systemd lacks start/stop service hooks (like in upstart) so it renders it pretty useless (or inconvenient in the least) in tasks like tracking service/system state.
So either adding ENV{SYSTEMD_WANTS}+=bluetooth to udev rule or create a pure systemd service/target which will be dependent on device and service and will do proper initialization/checks - smth like
[Unit]
Description=Bluetooth power keeper
Requires=sys-subsystem-bluetooth-devices-%i.device bluetooth.service
PartOf=sys-subsystem-bluetooth-devices-%i.device
After=bluetooth.service sys-subsystem-bluetooth-devices-%i.device suspend.target
Conflicts=shutdown.target systemd-sleep.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/dbus-send --system --type=method_call --dest=org.bluez /org/bluez/%I org.freedesktop.DBus.Properties.Set string:org.bluez.Adapter1 string:Powered variant:boolean:true
ExecStop=/usr/bin/dbus-send --system --type=method_call --dest=org.bluez /org/bluez/%I org.freedesktop.DBus.Properties.Set string:org.bluez.Adapter1 string:Powered variant:boolean:false
[Install]
WantedBy=bluetooth.target
But most probably you would want to reset hci state after sleep - otherwise bluez5 just becomes useless memory stuffing. And systemd is useless for that, unless you write a separate service for each state transition with own weird set of targets... *sigh* So back to the old school - pm-utils/acpid hacks... was it worth it?