RFE: "systemctl disable" on a disabled unit should probably print a quick message about that, instead of showing nothing

[ewtoombs]

Submission type

• [* ] Bug report
• Request for enhancement (RFE)

systemd version the issue has been seen with

232-8

Used distribution

archlinux

In case of bug report: Expected behaviour you didn't see

deliver error, suggest correct command (mask)

% systemctl --user disable pulseaudio.socket
No symlinks were deleted. No change has been made to the configuration.
Did you mean to use systemctl --user mask?
%

In case of bug report: Unexpected behaviour you saw

no errors, even though operation failed.

In case of bug report: Steps to reproduce the problem

% systemctl --user disable pulseaudio.socket
%

[poettering]

I am very strongly against the suggestion to use "systemctl mask", as masking is a last resort thing, the big hammer that you only use if you really really know what you do and are capable of handling such a big hammer. It's not something we should point people to, as it should not be part of normal workflow.

That said, it might make sense to log a quick message if a unit is asked to be disabled, but there's nothing to disable because it already is disabled.

[ewtoombs]

Well, if I want to disable a globally enabled user service like pulseaudio on startup but only for my user, how else would I do it? For system services, it is kind of nonsense, but for user services, it seems pretty natural and common to me. You'd only deliver the hint when it's a user service that somebody is trying to disable. Anyway, just the error message is still a huge improvement. Thanks for considering that.

[poettering]

There were discussions to permit "systemctl disable" on a system service carrying [Install] data which was enabled via symlinks in /usr, by creating /dev/null symlinks in /etc. This wasn't implemented so far, but it would deliver what you are asking for in the user case.

[ewtoombs]

Well, that would be cool. Is there an open issue for this? I'd like to follow it.

[poettering]

This is actually a duplicate of #4012.