Raspbian 10下systemd配置蓝牙就绪启动服务不生效问题

• 核心错误是依赖配置放错了段：Wants=bluetooth.target写在[Install]段完全无法实现「my.service依赖bluetooth.target」的效果。[Install]段的Wants作用是：当你执行systemctl enable my.service时，会在bluetooth.target.wants目录下创建my.service的软链接，逻辑是bluetooth.target启动时拉取my.service，和你需要的「my.service启动时拉取bluetooth.target」完全相反。依赖声明必须写在[Unit]段才会生效。
• 启动顺序约束After=的生效前提是两个单元都被纳入本次启动事务。你最初没在[Unit]段声明依赖，systemd启动时不会主动拉取bluetooth.target，After约束自然不会生效，你的服务会直接启动。
• 自定义服务放在/lib/systemd/system路径不符合规范：该路径是系统包维护的专属路径，自定义服务应该放在/etc/systemd/system路径下，优先级更高且不会被系统更新覆盖。

• 首先澄清一个常见误区：bluetooth.target的设计目标仅标记蓝牙守护进程bluetoothd启动完成，不代表蓝牙适配器已经上电、固件加载完成、可以正常使用。蓝牙适配器的初始化是bluetoothd启动后异步执行的，所以bluetooth.target进入激活状态时，蓝牙功能大概率还没就绪。
• 你看到的bluetooth.target配置里有After=bluetooth.service只是顺序约束：仅当bluetooth.service被纳入本次启动事务时才会等待它启动完成。如果你的bluetooth.service没有设置为开机自启，bluetooth.target启动时发现没有需要等待的单元，会直接进入激活状态，自然远早于蓝牙服务启动。你可以执行systemctl is-enabled bluetooth.service检查蓝牙服务的自启状态。

• 方案1（最简单稳定）：修改/root/my.sh脚本，开头增加蓝牙状态检测逻辑，轮询等待适配器就绪后再执行后续任务，示例逻辑如下：

#!/bin/bash
# 最多等待30秒蓝牙就绪
for i in {1..30}; do
    # 检测hci0适配器是否存在且已上电
    if hciconfig hci0 | grep -q "UP RUNNING"; then
        break
    fi
    sleep 1
done
# 你的后续业务逻辑

• 方案2（systemd原生实现）：如果你不希望在脚本里加检测逻辑，可以给bluetooth.service添加drop-in配置片段，增加同步等待蓝牙就绪的逻辑：
  1. 创建配置目录：mkdir -p /etc/systemd/system/bluetooth.service.d/
  2. 新建/etc/systemd/system/bluetooth.service.d/wait-adapter.conf，内容如下：

  [Service]
  ExecStartPost=/bin/bash -c 'while ! hciconfig hci0 | grep -q "UP RUNNING"; do sleep 1; done'
  

  3. 执行systemctl daemon-reload重载配置，之后bluetooth.service启动完成时就代表蓝牙适配器已经就绪，你修改后的my.service配置就可以正常工作。

内容的提问来源于stack exchange，提问作者Gildas