search

raspberrypi / bookworm-feedback

12 stars 1 forks source link

Disabling BT causes spurious systemd unit failure leading to 'degraded' system status #235

Closed psydbernz closed 3 months ago

psydbernz commented 3 months ago

When a stock recent ( eg. 2024-03-07 ) RasPiOS is installed, systemd status is "running". If BT is disabled via the GUI, then systemd status changes to "degraded" ( may require a reboot first ). 'systemctl status --failed' then indicates that "bthelper@hci0.service" has failed.

If BT is disabled, then BT-related services should stop, and when BT is enabled, all BT-related services should start again. Ideally, those starts / stops happen at runtime, in response to BT being enabled or disabled by the GUI ( or 'rfkill', which is used by the GUI mechanism ).

psydbernz commented 3 months ago

i've encountered at least one other person seeing the same kind of "fault" ( also having disabled BT ), including the same error messages.

spl237 commented 3 months ago

What model of Pi are you using, and are you using the Wayfire desktop or the X11/Openbox one?

ghollingworth commented 3 months ago

If you try "sudo bthelper hci0" from the command line it fails with "Operation not possible due to RF-kill" I think disabling Bluetooth should probably "systemctl disable @.***" as well

On Tue, 19 Mar 2024 at 18:13, Simon Long @.***> wrote:

What model of Pi are you using, and are you using the Wayfire desktop or the X11/Openbox one?

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/bookworm-feedback/issues/235#issuecomment-2007837999, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAPUEHAEAB4CFJTQ7BCBXSDYZB54XAVCNFSM6AAAAABE2O4KLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBXHAZTOOJZHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Gordon Hollingworth Chief Technology Officer - Software Raspberry Pi Limited +44 (0)1223 322633 +44 (0)7450 946289

spl237 commented 3 months ago

I don't see the problem as described. I see the exact opposite of the problem!

If I boot with BT enabled, I can enable and disable it with rfkill (and/or the GUI) as many times as I want, and that service remains active and happy.

The problem I see is that if I boot with BT disabled, then that service is never started - rfkill blocks it at boot, and unblocking BT with rfkill doesn't start the service, which makes a lot more sense as a failure mode.

It does make how to fix it a lot less obvious though, you can start the service after you have unblocked BT, but at present you need sudo to do that, which the panel doesn't have. Might be time to find yet another polkit rule - https://stackoverflow.com/questions/61480914/using-policykit-to-allow-non-root-users-to-start-and-stop-a-service

But I don't know if this actually causes problems, because I have just tried a bullseye image and it does exactly the same thing, so if this is indeed broken, it has been broken for years. Probably forever. So it is odd that no-one has ever noticed before...

spl237 commented 3 months ago

That polkit rule works on Debian bookworm, thankfully, so if we do want to start and stop that service along with rfkill, we can do so.

spl237 commented 3 months ago

Confirmed internally that this service is no longer needed, so its failure to run is not a problem. We will disable it by default in future releases.

psydbernz commented 3 months ago

@spl237 thanks for looking into this!

Indeed, the problem was about the lack of [runtime] "reaction" by the system to the toggling of BT enable / disable -- I'm just one of those fussy people who likes to see the systemd status as "running" ( not "degraded" ) when there's not a genuine problem.

But you confirming that the "failing" service is deprecated is good news; I'll just 'mask' that service until it's obviated by an update.