[systemd-devel] [RFC] inconsistent symlink handling

[Tom Gundersen]

Hi guys,

Whenever the name of a shipped unit file changes (e.g., in case we
move from a distro-specific one to an upstream one, and upstream
happened to chose a different name), we would like to be able to ship
a symlink from the old to the new name for the sake of compatibility.

In our cronie package, the rc script used to be called 'crond', but
the new service file is called 'cronie.service'. To avoid issues on
upgrades I'd like to ship a symlink:

/usr/lib/systemd/system/crond.service -> cronie.service

Is my usecase a reasonable one that we want to support?

It mostly works, in that "systemctl <start|stop|status|...>
crond.service" is equivalent to "systemctl <start|stop|status|...>
cronie.service". Moreover, both cronie.service and crond.service are
listed by "systemctl list-unit-files" and if crond.service is enabled,
then cronie.service is started on boot.

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.

Cheers,

Tom