It seems to me that, compared to cron/anacron, systemd timers currently offer reduced functionality and no clear benefit (I don't consider the act of uninstalling cron to have significant value in itself). Losing the ability to control when jobs run is giving up a lot; without that, the more use is made of systemd timers, the more unpredictable the results will be. Perhaps I'm missing something, because I don't fully understand all the points Thomas raised last month in his proposal on arch-dev-public: > Pros: > * enabled by default (in contrast to cronie) > * systems without need for crontabs can disable/uninstall cron > * service will be simpler than the rather long dropin scripts > > Cons: > * services are run in parallel instead of sequentially (is this even a > con? timer start will be randomized, and we can increase accuracy to an > hour to randomize even more) > * no holdoff time after boot as it seems pro#3 is a mystery to me, and missing from the "con" list is the point Maciej raised about the effect random timer jobs can have on busy servers. If this ship is already sailing, though, the goal should be to add functionality to systemd timers so that it becomes a real replacement for cron, e.g. allow execution windows to be defined, jobs placed within these windows, and scheduling parameters like acceptable degrees of parallelism to be specified. Something like that could be more powerful and flexible than cron, and potentially easier to manage than a set of crontabs. Does anyone know if the systemd timers roadmap includes anything like this? Carl
