[systemd-devel] [RFC] inconsistent symlink handling

[Peeters Simon]

> However, there is one issue:
>
> * "systemctl enable crond.service" does not work, but returns "Failed
> to issue method call: No such file or directory".
>
> Is this behaviors by design, or a bug? If this can not be solved by
> making "systemctl enable crond.service" equivalent to "systemctl
> enable cronie.service" as I would have hoped, then would it be
> reasonable to suggest that "systemctl list-unit-files" should not list
> anything as "disabled" that can not be "enabled"? I.e., treat it the
> same as a unit file with no [Install] section? That would also remove
> them from the bash-completion, and hence making it much less likely
> that people would come across this problem in the first case.

>From what i remember having read (somwhere on the list, but i can not
find this now)
this is by design: systemctl enable and disable do not work on
symlinks, the rationale given was something like this:

supose you have a service foo.service that has a Alias=bar.service

foo.service is enabled, so bar.service->foo.service

start and stop do not change anything to this situation and work both
for foo.service and bar.

but if one would do:
systemctl disable bar.service (and systemctl would not complain)
followed by
systemctl enable bar.service
the later would give an error, wich is counter intuitive for the user
(I just disabled something and i can not re-enable it)

so this is the reason why systemctl disable on a symlink should give
an error, what annoys me a little bit is the stile of the error, it
sould say something like:
could not disable bar.service since it is not the real service name,
try systemctl disable foo.service


Simon Peeters