Arch Linux

correct, use cronie.service or dcron.service, the symlink is purely for start, and possibly for initscripts compatibility

Since Tom added that symlink I'm sure he'll be delighted to tell us why. :)

I need to sort this out in systemd, or just drop all the symlinks I guess.

The reason for adding this was to avoid errors when arch-daemons.target is enabled, and people had DAEMONS=('crond' ...) in rc.conf.

With the symlink in place, this would then start cronie.service, rather than be a wrapper around the legacy /etc/rc.d/crond. Without the symlink this would in particular be problematic in case someone has enabled cronie.service, but still kept crond in DAEMONS (as both would be started).

It is correct that crond.service can not be enabled, but the "proper" service (cronie.service) must be used instead. On the one hand this is confusing as there is no indication which one should be used (unless you check which is a symlink and which is a real file), on the other hand it is good that people will not be able to start using crond.service, so that we will be able to drop it at some point.

I suppose the simplest fix would be to not show crond.service in "systemctl list-unit-files" (and then it will not appear in the bash completion for "systemctl enable cron<TAB>" either.

Alternatively, we could rip out all the symlinks, but I was hoping to do that once initscripts was thoroughly dead and buried and everyone had transitioned over successfully (as I still think it reduces problems).

Please. Rip out all the symlinks. If you want to keep this behavior, implement it as a list of "quirks" in initscripts (contained within the generator itself).

I'm removing the symlinks; complain while this remains in [testing] if you must.