Description
The Bluetooth settings page in cosmic-settings has hardcoded systemctl commands for managing the BlueZ service. This creates unnecessary coupling to systemd and prevents proper integration with OpenRC (and other non-systemd init systems).
Current Behavior
In cosmic-settings/src/pages/bluetooth/mod.rs (lines 1015-1047), there is a systemd module that directly calls systemctl commands:
systemctl start bluetooth - to activate the servicesystemctl enable --now bluetooth - to enable and start the servicesystemctl is-enabled bluetooth - to check if service is enabledsystemctl is-active bluetooth - to check if service is running
Impact
On OpenRC systems:
- The
systemctl is-active and systemctl is-enabled checks fail, so the application can't properly detect service status
- When BlueZ isn't running, the application tries to start it via
systemctl start bluetooth, which fails
- Users see the error "The bluetooth service could not be activated. Is BlueZ installed?" even though BlueZ is installed - it just can't be started because the systemctl command doesn't work
- Users must manually start the BlueZ service using
rc-service bluetooth start
When BlueZ is already running (started manually or by OpenRC), the actual Bluetooth functionality works fine because the core operations (scanning, pairing, connecting devices) are all handled via D-Bus communication with the BlueZ daemon (org.bluez), which is init-system agnostic. The systemctl calls are only used for service lifecycle management.
Expected Behavior
The code should detect the available init system and use the appropriate service management commands:
- systemd:
systemctl start/enable/is-active/is-enabled bluetooth
- OpenRC:
rc-service bluetooth start/stop, rc-update add bluetooth default, rc-service bluetooth status
Related Issues
This is separate from but related to issue #1955 which deals with hardcoded loginctl/localectl commands in the locale/region settings.
Environment
- Gentoo Linux with OpenRC
- COSMIC Epoch 1.0.11
- BlueZ installed and managed by OpenRC
Additional Context
The Bluetooth functionality works fine on OpenRC systems when BlueZ is already running because D-Bus handles all the actual Bluetooth operations. The systemctl calls are only for service management, which could be abstracted to support multiple init systems.
Description
The Bluetooth settings page in cosmic-settings has hardcoded
systemctlcommands for managing the BlueZ service. This creates unnecessary coupling to systemd and prevents proper integration with OpenRC (and other non-systemd init systems).Current Behavior
In
cosmic-settings/src/pages/bluetooth/mod.rs(lines 1015-1047), there is asystemdmodule that directly callssystemctlcommands:systemctl start bluetooth- to activate the servicesystemctl enable --now bluetooth- to enable and start the servicesystemctl is-enabled bluetooth- to check if service is enabledsystemctl is-active bluetooth- to check if service is runningImpact
On OpenRC systems:
systemctl is-activeandsystemctl is-enabledchecks fail, so the application can't properly detect service statussystemctl start bluetooth, which failsrc-service bluetooth startWhen BlueZ is already running (started manually or by OpenRC), the actual Bluetooth functionality works fine because the core operations (scanning, pairing, connecting devices) are all handled via D-Bus communication with the BlueZ daemon (
org.bluez), which is init-system agnostic. The systemctl calls are only used for service lifecycle management.Expected Behavior
The code should detect the available init system and use the appropriate service management commands:
systemctl start/enable/is-active/is-enabled bluetoothrc-service bluetooth start/stop,rc-update add bluetooth default,rc-service bluetooth statusRelated Issues
This is separate from but related to issue #1955 which deals with hardcoded
loginctl/localectlcommands in the locale/region settings.Environment
Additional Context
The Bluetooth functionality works fine on OpenRC systems when BlueZ is already running because D-Bus handles all the actual Bluetooth operations. The systemctl calls are only for service management, which could be abstracted to support multiple init systems.