Since bthelper is not a daemon, systemd thinks that the service is dead after it finishes executing. Changing the service type to oneshot will ensure systemd considers the service active after it finishes its course.
Behavior of oneshot is similar to simple; however, the service manager will consider the unit up after the main process exits. It will then start follow-up units
This allows us to write reliable service units that need to be ran before or after bthelper has started. My use case for example is that I need to disable SSP mode on the bluetooth controller after boot:
[Unit]
Description=Turn off bluetooth SSP mode
Wants=bthelper@%i.service
After=bthelper@%i.service
[Service]
Type=oneshot
ExecStart=/usr/bin/btmgmt -i %I ssp off
RemainAfterExit=yes
[Install]
WantedBy=bluetooth.target
What people would usually do for similar scenarios is that they would put arbitrary sleep calls before performing actions against the bluetooth controller in order to ensure that their actions get completed before bthelper runs and performs reinitialization (which would overwrite certain user-set settings in the process).
Since
bthelper
is not a daemon, systemd thinks that the service is dead after it finishes executing. Changing the service type tooneshot
will ensure systemd considers the service active after it finishes its course.From the systemd documentation:
This allows us to write reliable service units that need to be ran before or after
bthelper
has started. My use case for example is that I need to disable SSP mode on the bluetooth controller after boot:What people would usually do for similar scenarios is that they would put arbitrary
sleep
calls before performing actions against the bluetooth controller in order to ensure that their actions get completed beforebthelper
runs and performs reinitialization (which would overwrite certain user-set settings in the process).