Bug#928982: Bug: 'systemctl is-enabled' return enabled/true when alias symlinks exist

[Martin Olsson]

Package: systemd
Version: 232-25+deb9u11

Problem:
The command 'systemctl is-enabled myfoobar.target' return "enabled"
(exit code 0) when it should return "disabled" (code >0).

How to reproduce:
Create a symlink /etc/systemd/system/foo.target -->
/etc/systemd/system/myfoobar.target
either manually with 'ln -s' or via an "Alias=" in your unit file.

Without the alias symlink, 'systemctl is-enabled myfoobar.target'
return "disabled" just as it should.
When adding the symlink, 'systemctl is-enabled myfoobar.target'
suddenly return "enabled".
I think this is wrong.

The manual states:
--------------------------
is-enabled NAME...
Checks whether any of the specified unit files are enabled (as with
enable). Returns an exit code of 0 if at least one is enabled,
non-zero otherwise.
Prints the current enable status (see table). To suppress this output,
use --quiet. To show installation targets, use --full.
Result "enabled" (exit code 0) = Enabled via .wants/, .requires/ or
alias symlinks (permanently in /etc/systemd/system/, or transiently in
/run/systemd/system/).
--------------------------

Why should is-enabled report "enabled" on alias symlinks in
/etc/systemd/system/?
Aliases are just aliases, they don't automatically enable the
service/target/unit on boot.



How I found this issue:
I use Puppet to handle the state of my custom service (which is
actually a .target, with multiple services as Wants).
When Puppet check to see if the service 'myfoobar.target' is enabled,
it runs the command 'systemctl is-enabled myfoobar.target'. This
returns true (since I have an alias symlink
/etc/systemd/system/foo.target), so Puppet never force the service to
become enabled. :-(