When running a kernel without bluetooth support, bluetooth.service fails to
start with
bluetoothd[1640]: Failed to access management interface
bluetoothd[1640]: Adapter handling initialization failed
systemd[1]: bluetooth.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start Bluetooth service.
This causes an unnecessary "degraded" state and more importantly breaks package
installation when the bluez package auto-starts the daemon.
Add a condition to only start the service if /sys/class/bluetooth exists.
https://launchpad.net/bugs/1506774
---
src/bluetooth.service.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/bluetooth.service.in b/src/bluetooth.service.in
index 35e9457..83e4732 100644
--- a/src/bluetooth.service.in
+++ b/src/bluetooth.service.in
@@ -1,6 +1,7 @@
[Unit]
Description=Bluetooth service
Documentation=man:bluetoothd(8)
+ConditionPathIsDirectory=/sys/class/bluetooth
[Service]
Type=dbus
--
2.5.0
Hi Martin,
On Tue, Oct 20, 2015, Martin Pitt wrote:
> When running a kernel without bluetooth support, bluetooth.service fails to
> start with
>
> bluetoothd[1640]: Failed to access management interface
> bluetoothd[1640]: Adapter handling initialization failed
> systemd[1]: bluetooth.service: Main process exited, code=exited, status=1/FAILURE
> systemd[1]: Failed to start Bluetooth service.
>
> This causes an unnecessary "degraded" state and more importantly breaks package
> installation when the bluez package auto-starts the daemon.
>
> Add a condition to only start the service if /sys/class/bluetooth exists.
>
> https://launchpad.net/bugs/1506774
> ---
> src/bluetooth.service.in | 1 +
> 1 file changed, 1 insertion(+)
Applied. Thanks.
Johan
Hey Marcel,
Marcel Holtmann [2015-10-20 15:19 +0200]:
> > +ConditionPathIsDirectory=/sys/class/bluetooth
>
> and this is not a race condition? I mean that directory might be not
> present because the module has not yet been loaded. So strictly
> speaking the kernel has been compiled with Bluetooth support, but it
> has not been yet loaded. Are we not exchanged one issue for another?
If it's started automatically by a package or during boot and
bluetooth.service is started before the module loaded, won't it
currently fail anyway? With the condition it just won't be attempted
to start.
Remember though that this isn't the normal mode of operation --
normally bluetooth.target gets activated through udev if/when BT
hardware actually becomes available:
/lib/udev/rules.d/99-systemd.rules:SUBSYSTEM=="bluetooth", TAG+="systemd", ENV{SYSTEMD_WANTS}+="bluetooth.target"
and bluetooth.service hooks into that in its [Install]. This is race
free as only the completion of the module load and the appearance of
/sys/class/bluetooth triggers the above rule. (For that case it seems
systemd (re-)starts an already failed bluetooth.service as well.)
So in summary, this is a little cleanup, doesn't affect the main
"dynamic via udev" case, but unclutters startup requests which aren't
triggered by hardware.
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (http://www.ubuntu.com) | Debian Developer (http://www.debian.org)
Hi Martin,
> When running a kernel without bluetooth support, bluetooth.service fails to
> start with
>
> bluetoothd[1640]: Failed to access management interface
> bluetoothd[1640]: Adapter handling initialization failed
> systemd[1]: bluetooth.service: Main process exited, code=exited, status=1/FAILURE
> systemd[1]: Failed to start Bluetooth service.
>
> This causes an unnecessary "degraded" state and more importantly breaks package
> installation when the bluez package auto-starts the daemon.
>
> Add a condition to only start the service if /sys/class/bluetooth exists.
>
> https://launchpad.net/bugs/1506774
> ---
> src/bluetooth.service.in | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/bluetooth.service.in b/src/bluetooth.service.in
> index 35e9457..83e4732 100644
> --- a/src/bluetooth.service.in
> +++ b/src/bluetooth.service.in
> @@ -1,6 +1,7 @@
> [Unit]
> Description=Bluetooth service
> Documentation=man:bluetoothd(8)
> +ConditionPathIsDirectory=/sys/class/bluetooth
and this is not a race condition? I mean that directory might be not present because the module has not yet been loaded. So strictly speaking the kernel has been compiled with Bluetooth support, but it has not been yet loaded. Are we not exchanged one issue for another?
Regards
Marcel