Bug#928982: Bug: 'systemctl is-enabled' return enabled/true when alias symlinks exist
Hi! I don't know why you need it, since the bug is in systemctl, but here it is: #cat /etc/systemd/system/myfoobar.target [Unit] Description=MyFooBar (with 2 workers) Wants=foo1of2.service foo2of2.service [Install] WantedBy=multi-user.target Since Puppet use the exit-status from 'systemctl is-enabled', it is important that this query can be trusted. If you have a unit that is currently NOT enabled, the 'systemctl is-enabled' query should not say "enabled" just because an alias symlink exist. If I delete the alias symlink, the 'systemctl is-enabled' query says "disabled". Correct. If I create the alias symlink, the 'systemctl is-enabled' query says "enabled". Wrong! If I remove the alias symlink and manually run 'systemctl enable myfoobar.target', then the query says "enabled". Correct (since a wants-symlink now exist). Den tis 14 maj 2019 kl 17:19 skrev Michael Biebl : > > Am 14.05.19 um 16:58 schrieb 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). > > > Please share the full myfoobar.target > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? >
Bug#928982: Bug: 'systemctl is-enabled' return enabled/true when alias symlinks exist
Am 14.05.19 um 16:58 schrieb 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). Please share the full myfoobar.target -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#928982: Bug: 'systemctl is-enabled' return enabled/true when alias symlinks exist
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. :-(
