dron

> If you have hundreds of jobs like this you need a proper queue and neither cronie nor systemd is the right tool Eh sometimes, but you can get pretty far with one of two approaches: 1. Careful use of Requires= and Wants= to group your scripts into chains of jobs, which achieves fixed parallel (though at 100s of jobs, I hope you're generating those unit files with a tool like Puppet or https://github.com/karlicoss/dron or something and not doing this by hand). 2. Even better, just use a lockfile. `ExecStart="flock -F $TMPDIR/mylock <command>"` is pretty hard to beat. Use -F so as not to confuse KillMode and resource accounting and you're golden. Just don't use flock(1) timeouts; let systemd handle that. Heck, if you have that many cron jobs, you should be doing this even if you don't use systemd; otherwise job latency changes can cause re

I was annoyed by cron/fcron limitations and figured systemd is the way go because of its flexibility and power, but also was annoyed about manually managing tons of unit files. So I wrote a tool with a config that looks kinda like a crontab, but uses systemd (or launchd on mac) behind the scenes: https://github.com/karlicoss/dron#what-does-it-do E.g. a simplest job definition looks like this job(every(mins=10), 'ping https://beepb00p.xyz', unit_name='ping-beepb00p') But also it's possible to add more properties, e.g. arbirary systemd properties, or custom notification backends (e.g. telegram message or desktop notification) Since it's python, I can reuse variables, use for loops, import jobs from other files (e.g. if there are shared jobs between machines), and check if it's valid with mypy. Been using this for years now, and very happ

Some time ago I wanted the best bits from both worlds: - from cron: specifying all jobs in one file instead of scattering it across dosens of unit files. In 90% of cases I just want a regular schedule and the command, that's it - from systemd: mainly monitoring and logging. But also flexible timers, timeouts, resource management, dependencies -- for the remaining 10% of jobs which are a little more complicated So I implemented a DSL which basically translates a python spec into systemd units -- that way I don't have to remember systemd syntax and manually manage the unit files. At the same time I benefit from the simplicity of having everything in one place. An extra bonus is that the 'spec' is just normal python code - you can define variables/functions/loops to avoid copy pasting - you can use mypy to lint it before applying the change

- promnesia: a Memex-like tool to enhance my web browsing experience with more context and connections https://github.com/karlicoss/promnesia#readme - cachew: library that allows to cache python function calls in an sqlite database with just a single decorator (leveraging on type annotations) https://github.com/karlicoss/cachew#readme - dron: a friendlier 'frontend' for systemd which allows me to declare jobs as python code living in the same file -- combines best bits of systemd and cron https://github.com/karlicoss/dron#readme. I elaborate a bit more on motivation for it on my blog https://beepb00p.xyz/scheduler.html