You can create systemd timers and services quite easily with NixOS configuration : https://nixos.wiki/wiki/Nix_Cookbook
In search of a better job scheduler
11–20 of 30 posts
Re: In search of a better job scheduler
#12I don't get the systemd hate in this specific case. Their timers are pretty much the best possible option you have to schedule jobs, hands down. No cron Daemon is ever going to get there due to the lack of deep integration with the rest of the init system.
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! :)
Re: In search of a better job scheduler
#13Is there a reason not to consider apache airflow? https://airflow.apache.org/
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.
Re: In search of a better job scheduler
#14I don't get the systemd hate in this specific case. Their timers are pretty much the best possible option you have to schedule jobs, hands down. No cron Daemon is ever going to get there due to the lack of deep integration with the rest of the init system. 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…
Hey, author here!
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.
Re: In search of a better job scheduler
#15I don't get the systemd hate in this specific case. Their timers are pretty much the best possible option you have to schedule jobs, hands down. No cron Daemon is ever going to get there due to the lack of deep integration with the rest of the init system. 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…
Hey, author here! 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 '…
I think you should check out mcron, which is basically cron redone but in GNU guile (scheme) with more features. I think it fails some of your requirements (the syntax can be a bit more to wrap ones head around than standard cron), but it is powerful and seems promising.
https://www.gnu.org/software/mcron/manual/mcron.html#Introdu...
Re: In search of a better job scheduler
#16Jenkins works reasonably well as a job scheduler. The UI is functional if not pretty, it is fairly easy to configure and use even for a large number of jobs, and the plugin ecosystem allows you to extend it in many ways without writing any code.
If the only way to get a decent cron is to run a full blown Jenkins server it is time I quit the tech industry.
Re: In search of a better job scheduler
#17I don't get the systemd hate in this specific case. Their timers are pretty much the best possible option you have to schedule jobs, hands down. No cron Daemon is ever going to get there due to the lack of deep integration with the rest of the init system. 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…
I prefer snooze over cron for similar reasons. It is a transparent chain loaded command that you can integrate win any service supervisor.
Re: In search of a better job scheduler
#18Anyone have a good open source replacement for Autosys or controlM? Should be easy to replace but every enterprise I've seen still pays for one of those.
This! I am highly interested if anyone has any suggestions.
Re: In search of a better job scheduler
#19I keep wondering whether there's a job scheduler for me too, but not finding much. At work I'm using/writing a custom one: with multiple schedules in crontab format for each task, frequent automated task updates (by an identifier) from multiple sources, additional flags for some jobs to not run if the parameters didn't change, and/or to rerun every few hours to ensure that proper states are set. It still felt like a generic enough task to use an external tool with those requirements, but then additional functionality appeared, such as changing task parameters according to certain rules (and internal state). At this point it seems that the way to go is either a custom scheduler or just regular cron, crontab editing, and wrappers akin to cronic (or otherwise handling the state-related configuration in the tasks it runs) -- that is, also a custom scheduling system, but incorporating cron. Here cron's simplicity seems fine: say, prevention of duplicate tasks should be by those "task group" IDs, rather than just jobs listed in crontab (so even if cron had the latter, it wouldn't be useful).
Re: In search of a better job scheduler
#20I love all the options we have today.
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.