hciuart.service is not stopped on package removal/purge

[MichaIng]

When purging the pi-bluetooth package, the hciuart.service (hciattach process) is still running:

# systemctl is-active hciuart
active

debhelper seems to add a block to remove the service, but it doesn't seem to imply stopping it:

# Automatically added by dh_installsystemd/13.3.4
if [ "$1" = "remove" ]; then
        if [ -x "/usr/bin/deb-systemd-helper" ]; then
                deb-systemd-helper mask 'hciuart.service' >/dev/null || true
        fi
fi

if [ "$1" = "purge" ]; then
        if [ -x "/usr/bin/deb-systemd-helper" ]; then
                deb-systemd-helper purge 'hciuart.service' >/dev/null || true
                deb-systemd-helper unmask 'hciuart.service' >/dev/null || true
        fi
fi
# End automatically added section

Usually it doesn't cause issues, but in some scripting scenarios it does, and I think it is expected that a service which does not exist on the system anymore is not continued to run.

[XECDesign]

This is intentional in this case. We don't want the service being stopped or restarted on upgrade or remove. It would leave the bluetooth chip in an unusable state.

[MichaIng]

I just recognised this: After the service is stopped, it cannot be started anymore without rebooting first 🤔. Makes sense then so removing and re-installing the package does not fail. I'll adjust our scripting accordingly to not stop the service either.

[Mausy5043]

It would leave the bluetooth chip in an unusable state.

Just curious. What do you mean by "unusable state"? Do you mean it is possible to brick the chip, does it become a heater or does communicating with it become erratic? And how would a reboot affect that state?

[MichaIng]

I'm sure (but better for others to answer) that it doesn't break you chip. I guess it is a firmware limitation that the device feature remains "deactivated" once the service it stops and the reboot is required to reinit it, similar like some device tree overlays cannot be effectively loaded on runtime without a reboot.

[XECDesign]

More info here https://github.com/raspberrypi/linux/issues/2251

[Mausy5043]

Perhaps a warning message could be logged to the journal to inform users trying to debug this "unexpected" behaviour. Maybe something like "hciuart.service ignoring stop command to avoid causing instability issues." ?

[XECDesign]

Sounds like a good idea. If you'd like to send a PR, I think we'd add it. I guess you'd need to set KillMode=none and an appropriate ExecStop= command.