bluetooth fails randomly on all qemu
Description
Environment
relates to
Activity
Corentin Labbe December 16, 2019 at 8:18 AM
failling bluetooth (and ofono) services checks are now skipped according to bluetooth device tag.
Corentin Labbe December 16, 2019 at 7:59 AM
As discussed on IRC
bluetooth.service is setup (via bluetooth.target and systemd) to be started when a dongle is detected.
You can start it manually after boot fine. But during boot, there is a race between bluetooth kernel module probing and the bluetooth unit being tried to start.
we should make the bluetooth test conditional to the bluetooth lava tag
everthing else might be error-prone and intrusive wrt systemd unit file mangling and so on.
i checked upstream systemd master and it is still the same setup, so we probably don't want to derive
Corentin Labbe December 4, 2019 at 1:37 PM
But why the ExecStartPre=sleep 20 you tried didnt fix the problem ?
Jan-Simon Moeller December 3, 2019 at 3:48 PM
The boot log shows ths issue. The bluetooth stack takes until 13.39 to initialize fully, by then the bluetooth service is already started (and would not find the not yet ready /sys/class/bluetooth) .
Jan-Simon Moeller December 3, 2019 at 3:42 PM
If the
ConditionPathIsDirectory=/sys/class/bluetooth
Is removed, the bluetooth service will successfully start.
Details
Details
Assignee
Corentin LabbeReporter
Corentin LabbePriority
Critical
bluetooth service check fail randomly on qemu-arm, qemu-arm64, qemu-x86_64
Example for arm64 https://lists.automotivelinux.org/g/agl-test-reports/message/295
Example for x86_64 https://lists.automotivelinux.org/g/agl-test-reports/message/294
Sometimes the service is not started like for arm in
See https://lava.automotivelinux.org/scheduler/job/9475
When debugging, I found that starting bluetooth before service checks made the test succeed.
But on some other jobs (arm64/x86_64), the service is started.
Perhaps two distinct issue ?