Your message dated Wed, 15 May 2019 13:56:11 +0200
with message-id <[email protected]>
and subject line Re: Bug#928982: Bug: 'systemctl is-enabled' return
enabled/true when alias symlinks exist
has caused the Debian Bug report #928982,
regarding Bug: 'systemctl is-enabled' return enabled/true when alias symlinks
exist
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
928982: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928982
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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. :-(
--- End Message ---
--- Begin Message ---
Version: 241-3
Hi Martin
Am 14.05.19 um 22:51 schrieb Martin Olsson:
> 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
With v241 (on Debian buster) I get the following behaviour:
# systemctl status myfoobar.target
● myfoobar.target - MyFooBar (with 2 workers)
Loaded: loaded (/etc/systemd/system/myfoobar.target; disabled; vendor
preset: enabled)
Active: inactive (dead)
# ln -s myfoobar.target foo.target
# systemctl status myfoobar.target
● myfoobar.target - MyFooBar (with 2 workers)
Loaded: loaded (/etc/systemd/system/myfoobar.target; indirect; vendor
preset: enabled)
Active: inactive (dead)
# systemctl status foo.target
● myfoobar.target - MyFooBar (with 2 workers)
Loaded: loaded (/etc/systemd/system/myfoobar.target; indirect; vendor
preset: enabled)
Active: inactive (dead)
# systemctl is-enabled myfoobar.target
indirect
And the corresponding documentation says
>
> ├──────────────────┼──────────────────────────────────────────┼───────────┤
> │"indirect" │ The unit file itself is not enabled, but │ 0
> │
> │ │ it has a non-empty Also= setting in the │
> │
> │ │ "[Install]" unit file section, listing │
> │
> │ │ other unit files that might be enabled, │
> │
> │ │ or it has an alias under a different │
> │
> │ │ name through a symlink that is not │
> │
> │ │ specified in Also=. For template unit │
> │
> │ │ file, an instance different than the one │
> │
> │ │ specified in DefaultInstance= is │
> │
> │ │ enabled. │
> │
>
> ├──────────────────┼──────────────────────────────────────────┼───────────┤
So, afaics, everything is working as expected with v241. Closing for
that version accordingly.
I consider this a minor issue, as it's a rather special case. So I
probably won't invest any time myself in finding the commit(s) between
v232 and v241 which fixed that behaviour.
If you severely affected by this and willing to dig out the necessary
upstream commits and the changes themselves are not too invasive and
easily backportable, I will consider them for a stable upload.
Please let me know in this case, so I can usertag the bug report
accordingly.
Regards,
Michael
--
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
--- End Message ---
_______________________________________________
Pkg-systemd-maintainers mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
