Bug 56690 - MSG: when we disable a static unit we currently print no message, but we should
Summary: MSG: when we disable a static unit we currently print no message, but we should
Status: NEW
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
: 72855 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-11-02 18:45 UTC by nucrap
Modified: 2014-06-25 10:44 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

Attachments

Description nucrap 2012-11-02 18:45:30 UTC 
Systemd won't disable alsa-(re)store.service via "systemctl disable alsa-restore.service"
Only masking will successfully disable it. However that is a rather brute-force method. However it is also possible to just uninstall alsa-utils.

I know there aren't many reasons to disable the alsa-(re)store daemon.
I've had an issue with this because I use OSSv4 instead of ALSA. 
In my opinion AT LEAST a warning should be displayed that this service cannot be disabled. At first I didn't even notice that systemd just ignored my command. Only when I looked into the boot/shutdown logs I saw that alsa-(re)store.service  was actually still being launched.

Aside from that, in my opinion systemd shouldn't pull in the ALSA daemon as default. When somebody needs it, there's no obstacle in enabling it just as all the other daemons.
Comment 1 Lennart Poettering 2013-01-15 01:00:20 UTC 
It is indeed a bit confusing that "systemctl disable alsa-store.service" does nothing and does not write any message. We should fix that.
Comment 2 Lennart Poettering 2014-06-25 10:44:50 UTC 
*** Bug 72855 has been marked as a duplicate of this bug. ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.