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 (www.ubuntu.com) | Debian Developer (www.debian.org)
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
