Correct the dbus service file's systemd unit name for bluez.
PATCH 1/1 Correct the dbus service file's systemd unit name for bluez.
Even though dbus-org.bluez.service is set as an alias for the bluetooth.service systemd unit file, systemd will not be able to load the bluetooth daemon without the daemon being enabled (and the dbus-org.bluez.service file linked to bluetooth.service). This patch allows the daemon to be loaded by other services on demand.
--- src/org.bluez.service | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
src/org.bluez.service +1 -1
@@ -2,4 +2,4 @@ Name=org.bluez Exec=/bin/false User=root -SystemdService=dbus-org.bluez.service +SystemdService=bluetooth.service
Signature · 4 lines
1.8.1.2 -- William Douglas, Intel Open Source Technology Center
Marcel Holtmann
maintainerHi William,
Quoted 5 lines
Even though dbus-org.bluez.service is set as an alias for the bluetooth.service systemd unit file, systemd will not be able to load the bluetooth daemon without the daemon being enabled (and the dbus-org.bluez.service file linked to bluetooth.service). This patch allows the daemon to be loaded by other services on demand.
as you have noticed we have this in bluetooth.service:
[Install]
WantedBy=bluetooth.target
Alias=dbus-org.bluez.service
Isn't this exactly what we want anyway. The service must be enabled first before it will ever auto-started. Otherwise it just auto-starts and the user can never get rid of it.
Regards
Marcel
Hi Marcel,
Quoted 10 lines · Marcel Holtmann
Hi William,
Quoted 5 lines
Even though dbus-org.bluez.service is set as an alias for the bluetooth.service systemd unit file, systemd will not be able to load the bluetooth daemon without the daemon being enabled (and the dbus-org.bluez.service file linked to bluetooth.service). This patch allows the daemon to be loaded by other services on demand.
as you have noticed we have this in bluetooth.service:
Quoted 8 lines
[Install]
WantedBy=bluetooth.target
Alias=dbus-org.bluez.serviceIsn't this exactly what we want anyway. The service must be enabled first before it will ever auto-started. Otherwise it just auto-starts and the user can never get rid of it.
Oh I didn't realize that was the intent. Is that because if it is auto enabled there is no way for the service to be masked to avoid it from auto starting? I was hoping to have the daemon start once it was requested by default. Probably more of a distro choice though.
Marcel Holtmann
maintainerHi William,
Quoted 17 lines
Quoted 8 lines
Quoted 5 lines
Even though dbus-org.bluez.service is set as an alias for the bluetooth.service systemd unit file, systemd will not be able to load the bluetooth daemon without the daemon being enabled (and the dbus-org.bluez.service file linked to bluetooth.service). This patch allows the daemon to be loaded by other services on demand.
as you have noticed we have this in bluetooth.service:
Quoted 8 lines
[Install]
WantedBy=bluetooth.target
Alias=dbus-org.bluez.serviceIsn't this exactly what we want anyway. The service must be enabled first before it will ever auto-started. Otherwise it just auto-starts and the user can never get rid of it.
Quoted 4 lines
Oh I didn't realize that was the intent. Is that because if it is auto enabled there is no way for the service to be masked to avoid it from auto starting? I was hoping to have the daemon start once it was requested by default. Probably more of a distro choice though.
I am actually curious on what is the best way here. My current thinking is that the daemon should be started when hardware is present. Starting it only because of a UI applet seems silly if there is no hardware present, but I am not sure what's the appropriate default is here.
Regards
Marcel
Quoted 24 lines · Marcel Holtmann
Hi William,
Quoted 17 lines
Quoted 8 lines
Quoted 5 lines
Even though dbus-org.bluez.service is set as an alias for the bluetooth.service systemd unit file, systemd will not be able to load the bluetooth daemon without the daemon being enabled (and the dbus-org.bluez.service file linked to bluetooth.service). This patch allows the daemon to be loaded by other services on demand.
as you have noticed we have this in bluetooth.service:
Quoted 8 lines
[Install]
WantedBy=bluetooth.target
Alias=dbus-org.bluez.serviceIsn't this exactly what we want anyway. The service must be enabled first before it will ever auto-started. Otherwise it just auto-starts and the user can never get rid of it.
Quoted 4 lines
Oh I didn't realize that was the intent. Is that because if it is auto enabled there is no way for the service to be masked to avoid it from auto starting? I was hoping to have the daemon start once it was requested by default. Probably more of a distro choice though.
Quoted 4 lines
I am actually curious on what is the best way here. My current thinking is that the daemon should be started when hardware is present. Starting it only because of a UI applet seems silly if there is no hardware present, but I am not sure what's the appropriate default is here.
That is an interesting point. I was looking at it like I do for connman, where it will start even if there isn't any network interfaces currently available and that is expected behavior to me. Bluez could be waiting on a usb bluetooth adapter to be added just like connman is waiting on a usb ethernet adapter (and it isn't obvious to my that this is taking up a much in the way of resources or adding a lot of wakeups but I don't know). Either way I expect an easy to turn on and off UI component making either default simple to correct. Right now, the connman UI I am using just presents a bluetooth option for enable/disable but it doesn't work as is without the service being able to autostart without being enabled manually (or by the distro default).
Marcel Holtmann
maintainerHi William,
Quoted 27 lines
Quoted 22 lines
Quoted 17 lines
Quoted 8 lines
Quoted 5 lines
Even though dbus-org.bluez.service is set as an alias for the bluetooth.service systemd unit file, systemd will not be able to load the bluetooth daemon without the daemon being enabled (and the dbus-org.bluez.service file linked to bluetooth.service). This patch allows the daemon to be loaded by other services on demand.
as you have noticed we have this in bluetooth.service:
Quoted 8 lines
[Install]
WantedBy=bluetooth.target
Alias=dbus-org.bluez.serviceIsn't this exactly what we want anyway. The service must be enabled first before it will ever auto-started. Otherwise it just auto-starts and the user can never get rid of it.
Quoted 4 lines
Oh I didn't realize that was the intent. Is that because if it is auto enabled there is no way for the service to be masked to avoid it from auto starting? I was hoping to have the daemon start once it was requested by default. Probably more of a distro choice though.
Quoted 4 lines
I am actually curious on what is the best way here. My current thinking is that the daemon should be started when hardware is present. Starting it only because of a UI applet seems silly if there is no hardware present, but I am not sure what's the appropriate default is here.
Quoted 12 lines
That is an interesting point. I was looking at it like I do for connman, where it will start even if there isn't any network interfaces currently available and that is expected behavior to me. Bluez could be waiting on a usb bluetooth adapter to be added just like connman is waiting on a usb ethernet adapter (and it isn't obvious to my that this is taking up a much in the way of resources or adding a lot of wakeups but I don't know). Either way I expect an easy to turn on and off UI component making either default simple to correct. Right now, the connman UI I am using just presents a bluetooth option for enable/disable but it doesn't work as is without the service being able to autostart without being enabled manually (or by the distro default).
in general the Bluetooth option should only be present if you have bluetoothd running and at least one controller attached.
So my thinking is that attaching a controller will start bluetoothd and then connmand will pick up up and present Bluetooth as technology. So that should all work.
ConnMan actually detects at runtime the start/restart of bluetoothd.
Regards
Marcel