-
Notifications
You must be signed in to change notification settings - Fork 189
Systemd integration
Systemd (https://www.freedesktop.org/wiki/Software/systemd/) is now the most common system and service manager on mainstream linux distributions. The bluez-alsa project now includes systemd service unit files for the bluealsa daemon and the bluealsa-aplay utility.
There are many different scenarios in which BlueALSA may be used, and the flexibility of systemd's configuration files means that there are equally many ways that the BlueALSA service units can be configured. The unit files provided by the project are intended to give a flexible and secure basis that can be used out-of-the box in the most common scenarios but can also be easily customized for any specialized use-case.
The BlueALSA systemd unit files are not installed by default, they must be explicitly enabled when configuring the build by including the configure option --enable-systemd. See Installation from source for more information on build and install procedure for BlueALSA.
There are also some configure options that can modify the unit files, setting the command-line arguments and setting the user id under which each service should be started. By default both services are run as user root. bluealsa is started with bluealsa -p a2dp-source -p a2dp-sink and bluealsa-aplay is started with no arguments. See the respective manual pages for full details of all available command-line arguments bluealsa manual page, bluealsa-aplay manual page.
It is generally considered best practice not to run services as root unless absolutely necessary. Neither of the BlueALSA services need root privileges, so long as the accounts they use have the required group memberships, and for bluealsa D-Bus permission is correctly granted to the chosen user. For maximum security, the chosen user accounts should be "system" accounts, which means each should:
- have its own group
- have no home directory
- have no shell
- have logins disabled
Distributions vary in the way that user and group accounts are created, so you should consult you distribution's documentation for instructions. As an example, on Debian and derivatives you can create suitable accounts called bluealsa and bluealsa-aplay with
sudo adduser --system --group --no-create-home bluealsa
sudo adduser --system --group --no-create-home bluealsa-aplay
sudo adduser bluealsa-aplay audio
If you are using bluez 5.50 or older you will also need to add the bluealsa user to the bluetooth group:
sudo adduser bluealsa bluetooth
(Note that adduser is a Debian utility; other distributions will likely have alternative utilities, each with its own command-line syntax).
Once the installation is complete, systemd needs to be informed of the new services by running (as root)
systemctl daemon-reload
If using BlueALSA v3.1.0 or earlier, systemd unit files are not included in the sources. The file templates can be obtained from the latest sources: bluealsa service file template and bluealsa-aplay service file template. It is necessary to modify the User= and ExecStart= directives in both templates then save them without the .in suffix to create usable systemd service files. For example, the bluealsa.service file may be edited to contain the lines
User=root
ExecStart=/usr/bin/bluealsa -p a2dp-source -p a2dp-sink
Please consult your distribution's documentation or the systemd documentation if you need help with using systemd services.
The service unit files can be used to start bluealsa and bluealsa-aplay when the bluetooth subsystem starts (typically at boot) by "enabling" them:
sudo systemctl enable bluealsa.service
sudo systemctl enable bluealsa-aplay.service
Note that if using bluealsa-aplay with HFP or HSP (bluealsa-aplay --profile-sco) then it should not be started at boot on a gateway host (HFP-AG or HSP-AG); this is because it will cause bluealsa to aquire the SCO transport as soon as a device connects, even though there may be no audio stream available in either direction at that time. This will waste bandwidth and battery power on the remote device. It is OK to start bluealsa-aplay at boot on a hands-free/headset host (HFP-HF or HSP-HS) because in that role bluealsa will not immediately acquire the transport.
It is also possible to start and stop either service manually, whether "enabled" or not, for example:
sudo systemctl start bluealsa.service
sudo systemctl stop bluealsa.service
When BlueALSA is built with the option --enable-debug the bluealsa daemon and bluealsa-aplay application both produce large amounts of debug output. This output is sent to stderr, which by default systemd redirects to its journal file. This makes such builds less suitable for use with systemd, especially on embedded and other small systems with limited file space. It is therefore recommended not to run debug builds using systemd.
If you do need to run debug builds from systemd for any reason, then the logs will be visible using the systemd journalctl utility. For example:
sudo journalctl -xeu bluealsa.service
sudo journalctl -xeu bluealsa-aplay.service