My favourite thing with timers is we can finally use expressions for things like 'every second week' (W/2). Cron can't do "every 14 days" without firing a wrapper, and letting the wrapper decide if this was the right day.
I think it’s fairly common. Sometimes I want to do things every second/fourth Saturday. Then something else every first/third. Then there is the question of what to do when you have a fifth Saturday.
I have a lot of tasks that interact with the outside world, so I end up with schedules that look more human - the first monday of the month, every second thursday, etc.
For administration tasks, sure - for most things it's a choice between doing it overnight when it's quiet, or on sundays when it's all-day quiet. But for anything where humans dictate the schedule, it gets meatbaggy quickly.
I learned to love Systemd and Systemd timers only with NixOS that uses Systemd heavily. I built custom helper modules to make adding new “cron jobs” easy.
Nowadays System-V init scripts feel so old-school. It took only 15 years for me to start appreciating Systemd.
Nowadays System-V init scripts feel so old-school.
Because they are. The systemd naysayers basically boil down to a bunch of people that refuse to change, because what "they already have" is "good enough" or "works for them".
I'd love them more if I could combine conditions and make task to run once per week and one hour after boot. But no, currently systemd allows to set any one of those conditions, and I will have to do scripting to do the other one.
I’m a longtime cron fan. But there are things you can do so much more easily with a systemd timer. For example, say you have 100 systems and you want them all to execute something network-heavy at midnight. With systemd timers, you can EASILY add a builtin delay, and pick a random spread. So you can say, “run at midnight with a random delay between 0 and 1200 seconds”.
In OpenBSD cron and presumably other cron implementations you can use ~ to pick something at random. So to fire at a random minute at the midnight hour you can do:
One really cool thing that’s not mentioned in the article: Systemd timers are still ‘regular’ units.
This means you can group timers in a slice unit, which, on newer versions of systemd, lets you do impose a concurrency limit on a group of timers without having to deal with external locking.
wosmo@reddit
My favourite thing with timers is we can finally use expressions for things like 'every second week' (W/2). Cron can't do "every 14 days" without firing a wrapper, and letting the wrapper decide if this was the right day.
Inevitable_Taro4191@reddit
Systemd timers and conditional executions with if statements is soon a new Language
autogyrophilia@reddit
Which is nice, but, realistically, how often do you come across something like that.
The ability to fire at specific times, much more important in my books.
Also the much better logging.
mrsockburgler@reddit
I think it’s fairly common. Sometimes I want to do things every second/fourth Saturday. Then something else every first/third. Then there is the question of what to do when you have a fifth Saturday.
Reasonable_Working47@reddit
Is the common use case for alternating some logic between a primary/backup pair?
autogyrophilia@reddit
The common usecase is a oneoff task that you want to do off hours.
Not that doing it with sleep or with if and date was particularly hard, but it's way clearer.
wosmo@reddit
I have a lot of tasks that interact with the outside world, so I end up with schedules that look more human - the first monday of the month, every second thursday, etc.
For administration tasks, sure - for most things it's a choice between doing it overnight when it's quiet, or on sundays when it's all-day quiet. But for anything where humans dictate the schedule, it gets meatbaggy quickly.
ranjop@reddit
I learned to love Systemd and Systemd timers only with NixOS that uses Systemd heavily. I built custom helper modules to make adding new “cron jobs” easy.
Nowadays System-V init scripts feel so old-school. It took only 15 years for me to start appreciating Systemd.
Infinity-of-Thoughts@reddit
Because they are. The systemd naysayers basically boil down to a bunch of people that refuse to change, because what "they already have" is "good enough" or "works for them".
UsernameIsTaken45@reddit
Can I ask what kind of tasks and use cases ?
Barafu@reddit
I'd love them more if I could combine conditions and make task to run once per week and one hour after boot. But no, currently systemd allows to set any one of those conditions, and I will have to do scripting to do the other one.
AnsibleAnswers@reddit
You can do
[Timer] OnBootSec=1h OnUnitActiveSec=1w
itouchdennis@reddit
Finally systemd timer for my initd service file that executes a oneshot on startup /s
Jokes besides. Systemd timers are great, but I still do more crons instead of timers just because I am used to
mrsockburgler@reddit
I’m a longtime cron fan. But there are things you can do so much more easily with a systemd timer. For example, say you have 100 systems and you want them all to execute something network-heavy at midnight. With systemd timers, you can EASILY add a builtin delay, and pick a random spread. So you can say, “run at midnight with a random delay between 0 and 1200 seconds”.
tav_stuff@reddit
In OpenBSD cron and presumably other cron implementations you can use ~ to pick something at random. So to fire at a random minute at the midnight hour you can do:
mrsockburgler@reddit
That’s awesome. I didn’t know that!
ahferroin7@reddit
One really cool thing that’s not mentioned in the article: Systemd timers are still ‘regular’ units.
This means you can group timers in a slice unit, which, on newer versions of systemd, lets you do impose a concurrency limit on a group of timers without having to deal with external locking.
Zomunieo@reddit
You Don’t Hate Stupid Headlines That Tell You Hoe to Think and Feel Enough
spyingwind@reddit
MatchingTurret@reddit
It's not how Unix V7 did it, so this is a blasphemous violation that needs to be burned on the stake!