> 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
