I know it takes a while to get used to the ini file madness, but honestly, I can't detect so much boilerplate there: every single line in my units and timers makes sense.
If you're not familiar with that system yet, I can only encourage you to at least take a look at systemd timers. They are really cool! :)
Hope it doesn't read like I meant hate to systemd, please let me know where if you feel like I did! I guess some of the cons I listed count as subjective, but I doubt anyone would argue that adjusting a systemd job is easier than cron job :) Also I emphasised that I had non-tecnhical user in mind, who would definitely have hard time understanding what are 'timers', and why their job type has to be 'Simple'.
But I agree that forcing cron into doing what it wasn't meant for isn't probably going to go anywhere. That's why I suggested that using systemd as a backend is probably the most reasonable option after all, if only there was a friendlier tool to make the process as simple as with cron.
https://www.gnu.org/software/mcron/manual/mcron.html#Introdu...
You could run it on a digital ocean droplet so you don't have to worry about your laptop turning off. It covers retry and cron-style job kickoffs.
At Cronitor we are seeing a lot of users migrating to Airflow, Kubernetes cron jobs, and scheduled lambdas.
Like databases, different workloads will benefit from different guarantees. Look for the right tool for the job, not the right tool for all time.
It was created to manage weather forecast model runs. The new version which we are working on will have a simpler web GUI to replace its old PyGTK and Py2.
It handles o ly scheduling, and supports cyclic graphs (contrary to most workflow managers build with DAGs only).
No Python API yet, but coming in future release. So only a custom suite.rc INI style file that supports Jinja2 too.
dependencies, timeouts, resource policies and retries without hacky wrappers and boilerplate »
This is what I miss.
There's a strange gap in traditional Unix there, compared to other time-sharing systems. I have a feeling that if Unix had had a primitive job manager then by 1990 there would have been a pile of Gnu extensions and by 2000 there would have been people reinventing it, and GUIs that looked a bit like what you get to monitor print queues.
create ical event+repeat+alert=Custom(Open file)
this will open a file every repeat event. The file can be shell/workflow or whatever you want to run.
As a result, I can execute it include it in another ansible role, or use bigsudo to apply it as a one-off command:
bigsudo yourlabs.timer @somehost name=your-backup cmd=/your/backup.sh oncalendar='*-*-* 00:00:00 Europe/Paris'You can specify memory, CPU, retries, monitor, and run on many computers.
I think Kube is like systemd + cron + containers had a baby.