On Fri, 25 Apr 2014 17:19:04 -0400 Carl Schaefer <schaefer@trilug.org> wrote:
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).
But then again, you don't maintain the cron package...
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.
See systemd.timer(5) manpage. The timer configuration _should be_ one-to-one equivalent to a crontab, except for a different syntax...
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,
Just compare {man-db,logrotate,updatedb}.service files with the corresponding scripts in cron.daily...
and missing from the "con" list is the point Maciej raised about the effect random timer jobs can have on busy servers.
So far, I have seen only (minor) inconveniences associated with switching to the timers, which essentially have to do with system(d) startup time. Notice that these issues will not be visible on servers because there systemd's parallellization of the boot process is irrelevant. The timer jobs are niced to 19 so if the server is busy they should wait, no?
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?
Ask this on [systemd-devel]. Cheers, L. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D