[SOLVED] Activate bluetooth controller on boot

tolga9009 · 2013-07-07 02:13:47

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)

2ManyDogs · 2013-07-07 02:15:17

Does this help: https://wiki.archlinux.org/index.php/Bl … stallation

tolga9009 · 2013-07-07 02:18:18

Thanks for your reply. I have already started and enabled the bluetooth service. It only starts bluetooth daemon, but doesn't activate my bluetooth controller. I need to manually start it with the commands from Post #1.

//Edit: I've created a udev rule, which seems to work!

Create new file /etc/udev/rules.d/10-local.rules

# Set bluetooth power up
ACTION=="add", KERNEL=="hci0", RUN+="/usr/bin/hciconfig hci0 up"

Did I miss anything? There were lots of other options, like SUBSYSTEM and so on and I wasn't quite sure, if I really need them. It's working without them though.
The problem seems to be bluez 5, which doesn't start the bluetooth adapter on boot anymore

The adapter power state is not stored persistently and remembered over bluetoothd restarts. An external entity (like ConnMan) is expected to handle this.

Hopefully this one will help some people with the transition from bluez4 to bluez.

//Edit2: Well, this solution is now persistently working for me; there are no power-saving issues like with ConnMan. And this solution doesn't involve any further packages and daemons. No error logs so far. I'll mark it as solved. Still, if someone has any improvements for the udev rule, just post them!

Last edited by tolga9009 (2013-07-07 22:10:50)

ruff · 2013-08-06 20:07:27

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?

graysky · 2013-12-09 00:07:57

@tolga - thanks for this post. I updated the Bluetooth wiki page with your udev code.

NeilMunday · 2016-12-04 16:34:19

Hi,

I have used the following udev rule in /etc/udev/rules.d/10-local.rules as per: https://wiki.archlinux.org/index.php/bluetooth under Arch Linux to automatically start my Bluetooth adpater at boot time:

ACTION=="add", KERNEL=="hci0", RUN+="/usr/bin/hciconfig %k up"

Until last week when systemd was updated my udev rule does not appear to run as the bluetooth adapter is in its default state of "DOWN".

If I revert to a back-up image (which has an older version of systemd) the rule works fine.

Also, if I run

 udevadm test /sys/devices/pci0000\:00/0000\:00\:06.0/usb1/1-2/1-2\:1.0/bluetooth/hci0

the rule is shown as being triggered:

[root@arch ~]# udevadm test /sys/devices/pci0000\:00/0000\:00\:06.0/usb1/1-2/1-2\:1.0/bluetooth/hci0
calling: test
version 232
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

=== trie on-disk ===
tool version:          232
file size:         8441128 bytes
header size             80 bytes
strings            1846968 bytes
nodes              6594080 bytes
Load module index
Found container virtualization none
timestamp of '/etc/systemd/network' changed
Parsed configuration file /usr/lib/systemd/network/99-default.link
Created link configuration context.
timestamp of '/etc/udev/rules.d' changed
Reading rules file: /usr/lib/udev/rules.d/10-dm.rules
Reading rules file: /etc/udev/rules.d/10-local.rules
Reading rules file: /usr/lib/udev/rules.d/11-dm-lvm.rules
Reading rules file: /usr/lib/udev/rules.d/13-dm-disk.rules
Reading rules file: /usr/lib/udev/rules.d/50-udev-default.rules
Reading rules file: /usr/lib/udev/rules.d/60-block.rules
Reading rules file: /usr/lib/udev/rules.d/60-cdrom_id.rules
Reading rules file: /usr/lib/udev/rules.d/60-drm.rules
Reading rules file: /usr/lib/udev/rules.d/60-evdev.rules
Reading rules file: /usr/lib/udev/rules.d/60-pcmcia.rules
Reading rules file: /usr/lib/udev/rules.d/60-persistent-alsa.rules
Reading rules file: /usr/lib/udev/rules.d/60-persistent-input.rules
Reading rules file: /usr/lib/udev/rules.d/60-persistent-storage-tape.rules
Reading rules file: /usr/lib/udev/rules.d/60-persistent-storage.rules
Reading rules file: /usr/lib/udev/rules.d/60-persistent-v4l.rules
Reading rules file: /usr/lib/udev/rules.d/60-serial.rules
Reading rules file: /etc/udev/rules.d/60-vboxadd.rules
Reading rules file: /usr/lib/udev/rules.d/63-md-raid-arrays.rules
Reading rules file: /usr/lib/udev/rules.d/64-btrfs.rules
Reading rules file: /usr/lib/udev/rules.d/64-md-raid-assembly.rules
Reading rules file: /usr/lib/udev/rules.d/69-dm-lvm-metad.rules
Reading rules file: /usr/lib/udev/rules.d/70-mouse.rules
Reading rules file: /usr/lib/udev/rules.d/70-power-switch.rules
Reading rules file: /usr/lib/udev/rules.d/70-touchpad.rules
Reading rules file: /usr/lib/udev/rules.d/70-uaccess.rules
Reading rules file: /usr/lib/udev/rules.d/71-seat.rules
Reading rules file: /usr/lib/udev/rules.d/73-seat-late.rules
Reading rules file: /usr/lib/udev/rules.d/75-net-description.rules
Reading rules file: /usr/lib/udev/rules.d/75-probe_mtd.rules
Reading rules file: /usr/lib/udev/rules.d/78-sound-card.rules
Reading rules file: /usr/lib/udev/rules.d/80-drivers.rules
Reading rules file: /usr/lib/udev/rules.d/80-net-setup-link.rules
Reading rules file: /usr/lib/udev/rules.d/90-vconsole.rules
Reading rules file: /usr/lib/udev/rules.d/95-dm-notify.rules
Reading rules file: /usr/lib/udev/rules.d/99-systemd.rules
rules contain 24576 bytes tokens (2048 * 12 bytes), 12060 bytes strings
1776 strings (22269 bytes), 1177 de-duplicated (10809 bytes), 600 trie nodes used
RUN '/usr/bin/hciconfig %k up' /etc/udev/rules.d/10-local.rules:1
created db file '/run/udev/data/+bluetooth:hci0' for '/devices/pci0000:00/0000:00:06.0/usb1/1-2/1-2:1.0/bluetooth/hci0'
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:06.0/usb1/1-2/1-2:1.0/bluetooth/hci0
DEVTYPE=host
SUBSYSTEM=bluetooth
SYSTEMD_ALIAS=/sys/subsystem/bluetooth/devices/hci0
SYSTEMD_WANTS=bluetooth.target
TAGS=:systemd:
USEC_INITIALIZED=10993834
run: '/usr/bin/hciconfig hci0 up'
Unload module index
Unloaded link configuration context.
[root@arch ~]#

If I run the hciconfig command myself it brings up the Bluetooth adapter fine.

Could this be a bug in systemd?

Thanks,

Neil.

WorMzy · 2016-12-04 20:37:30

Please do not necrobump. Open a new topic for your issue and link back to this one as a reference if you need to.

Closing.

Arch Linux

#1 2013-07-07 02:13:47

[SOLVED] Activate bluetooth controller on boot

#2 2013-07-07 02:15:17

Re: [SOLVED] Activate bluetooth controller on boot

#3 2013-07-07 02:18:18

Re: [SOLVED] Activate bluetooth controller on boot

#4 2013-08-06 20:07:27

Re: [SOLVED] Activate bluetooth controller on boot

#5 2013-12-09 00:07:57

Re: [SOLVED] Activate bluetooth controller on boot

#6 2016-12-04 16:34:19

Re: [SOLVED] Activate bluetooth controller on boot

#7 2016-12-04 20:37:30

Re: [SOLVED] Activate bluetooth controller on boot

Board footer