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. :-(
