[This is a comment to arch-dev-public thread "Use systemd timers
instead of /etc/cron.{hourly, daily, weekly, monthly}?". As I was
unable to post to that list, I am following instructions provided by
the list server by sending this message to arch-general and the author
of the original thread. I'd like to mention that I also tried and was
not able to file a bug report on this issue, due to bug tracker server
failing to send a registration code. The original thread can be viewed
here: http://comments.gmane.org/gmane.linux.arch.devel/20644 ]
I am sorry to say that the decision to replace cron.daily tasks with
systemd timers is causing problems. After a routine update I noticed
that my machines now perform daily maintenance tasks exactly at
midnight. Not only is this time not optimal (too early), but all
machines perform their maintenance at the same moment, which is far
from ideal, especially for servers. Previously I had each server to
perform daily cron jobs at various times, spread between 3 and 6am. On
my machines this affects updatedb, man-db, logrotate and shadow,
updatedb generating a lot of I/O and thus being the most problematic.
I was not able to find any way to configure systemd to fire daily
calendar timers at a different time of the day (please correct me if I
missed something). So far I found two workarounds:
1. Override timer files and set OnCalendar with a specific time,
rather than "daily". This has to be done separately for each timer.
2. Restore cron.daily scripts and mask relevant systemd services and
timers (i.e. revert the configuration to what it was before the
update). The resulting config is simpler to manage than the first
workaround (no separate time settings for each task), so I went with
this one.
I am not sure what to suggest as a general fix for this issue, other
than a feature request to systemd upstream maintainers. I guess it is
too late to roll back the changes in affected Arch packages. I am
posting this for other users looking for a solution to this problem.
Thanks
Maciej Puzio
