Bug#932209: [ALSA] alsa-state.service starts daemon due to wrong ConditionPathExists

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#932209: [ALSA] alsa-state.service starts daemon due to wrong ConditionPathExists

MichaIng
Package: alsa-utils
Version: 1.1.8-2

Expected behaviour:
- alsa-state.service starts, if state-daemon.conf exists.
- alsa-restore.service starts, if state-daemon.conf does NOT exist.

Actual behaviour:
- Both systemd units start if state-daemon.conf exists.
- So alsactl daemon is always started on boot and can only prevent this
via "systemctl mask alsa-state" currently.

This does not match the explaining comments in both both systemd units
and it does not match version 1.1.3-1 (current Stretch package), nor the
source code, that was last changed 2017, so I could not open a pull
request to fix:
https://salsa.debian.org/alsa-team/alsa-utils/blob/debian/master/alsactl/alsa-state.service.in

I am not sure how this wrong code could find its way into
Buster+Bullseye+Sid repos, but it did:
https://deb.debian.org/debian/pool/main/a/alsa-utils/alsa-utils_1.1.8-2_amd64.deb

____________________________________
 > systemctl cat alsa-state.service
# /lib/systemd/system/alsa-state.service

# Note that two different ALSA card state management schemes exist and they
# can be switched using a file exist check - /etc/alsa/state-daemon.conf .
#

[Unit]
Description=Manage Sound Card State (restore and store)
Documentation=man:alsactl(1)
ConditionPathExists=!/etc/alsa/state-daemon.conf
After=sysinit.target

[Service]
Type=simple
ExecStart=-/usr/sbin/alsactl -E HOME=/run/alsa -s -n 19 -c rdaemon
ExecStop=-/usr/sbin/alsactl -E HOME=/run/alsa -s kill save_and_quit
____________________________________
 > systemctl cat alsa-restore.service
# /lib/systemd/system/alsa-restore.service
#
# Note that two different ALSA card state management schemes exist and they
# can be switched using a file exist check - /etc/alsa/state-daemon.conf .
#

[Unit]
Description=Save/Restore Sound Card State
Documentation=man:alsactl(1)
ConditionPathExists=!/etc/alsa/state-daemon.conf
ConditionPathExistsGlob=/dev/snd/control*
After=alsa-state.service

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=-/usr/sbin/alsactl -E HOME=/run/alsa restore
ExecStop=-/usr/sbin/alsactl -E HOME=/run/alsa store
____________________________________

Best regards

Reply | Threaded
Open this post in threaded view
|

Bug#932209: [ALSA] alsa-state.service starts daemon due to wrong ConditionPathExists

Ryan Tandy-4
On Tue, Jul 16, 2019 at 05:12:59PM +0200, [hidden email] wrote:
>Expected behaviour:
>- alsa-state.service starts, if state-daemon.conf exists.
>- alsa-restore.service starts, if state-daemon.conf does NOT exist.
>
>Actual behaviour:
>- Both systemd units start if state-daemon.conf exists.
>- So alsactl daemon is always started on boot and can only prevent
>this via "systemctl mask alsa-state" currently.

It looks like this was done intentionally, to fix #925455. The changelog
entry is written:

> * Introduce Fix-alsactl-to-restore-config.patch. Don't rely on undocumented
>   /etc/alsa/state-daemon.conf to start alsa-state.service.  alsa-restore.service
>   now will have an error code 99 the first time it runs. But after an reload of
>   the service or just a reboot both services will run smoothly.
>   [closes: #925455]

But that introduces exactly this issue; like you, I want one service or
the other running, not both!

There is a 1.1.8-3 version pending in git, with what looks to me like a
better solution (commit d8e09154), unfortunately not uploaded yet...

Reply | Threaded
Open this post in threaded view
|

Bug#932209: [ALSA] alsa-state.service starts daemon due to wrong ConditionPathExists

MichaIng
You are right, the change was reverted (partly) which is the reason why
I couldn't find the bug on Git.

Indeed the other issue is that, if the state-daemon.conf exists, none of
the two services starts.

The initial bug that caused this "bad" fix is also something I recognise
on e.g. Stretch systems. One must safe audio controls one time manually
and at best start alsa-restore.service once to have it storing on
shutdown and restoring on boot automatically.

If I am not mistaken, after back and forth, this initial "bug" is now
unresolved again. The problem is that alsa-restore.service does now
still not start, if the state file does not exist, thus does not store
states on shutdown, thus will never be active without manual storing:
https://salsa.debian.org/alsa-team/alsa-utils/blob/debian/master/alsactl/alsa-restore.service.in#L10
Removing that condition was already mentioned in the comments and IMO
totally makes sense. ExecStart already allows the failure, thus service
state will be active, thus ExecStop will be called after which
everything will be as intended.
Another solution of course would be to either include "alsactl store"
into the package postinst script or create an empty file (if not
existent) or something similar, but the above is more failsafe if for
some reason the state file gets removed.

Best regards,
Micha