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