Hacker News Reader

Comment by torstenvl | Hacker News Reader

Can you elaborate? I'm a macOS laptop/FreeBSD server guy. What are systemd timers, how do they work, and why do you feel they solve your problem better?

View on HN

Generally I would say the biggest difference is that with timers, you get more control.

For example, you can schedule a timer to run 10 minutes after boot. Or a timer that actives 10 minutes after it has last finished running (note: not when it started last time but when it finished! So if the proc takes 10 hours, there is a 10 minute gap between runs. If it takes 10 minutes, there is still a 10 minute gap).

You can also schedule something 10 minutes after a user logs in (or 10 seconds later, etc.).

Additionally you get Accuracy and RandomizedDelay. The former lets you configure how accurate the timer needs to be, down to 1 sec or up to a day. So your unit now runs somewhere on the day it's supposed to run. And with the later you can ensure that there is no predictable runtime, this can be important for monitoring.

My biggest favorite is Persistent=. If true, systemd will check when the service last ran. And if it should have been scheduled atleast once since then, it'll activate. I use this for backing up my home PC. When I do a quick restart, no backups are done but when I shutdown for the night, first thing in the morning my PC has a backup done.

Counterpoint is that I've never had a requirement for timing scenarios like this, so now I'm dragging all that along for the ride for no advantage. Bloat is great when you need that rare thing I guess; otherwise it's just bloat and complexity for no benefit.

Maybe because you've never had the ability to use such timing requirements. Having more advanced tools available also makes you think more in them. If you only ever used cron, there has been no reason to think about a service running every hour or immediately if it missed the schedule. Because the only tools are every hour and on reboot. And no option to make "every hour" mean "between script invocations" instead of "on the hour of the schedule".

This was my experience. Cron was great because it did what I needed it to do and I knew how to use it. But over the years I accumulated all sorts of hacks to avoid pitfalls. When I learned systemd timers I didn't like the complexity, but as new needs arose I thought about both cron and systemd and realized that systmd timers were better for 75% of my needs.

There are lots of things that I have the ability to do that I've never had the requirement to do. I call those things "bloat" because they are unnecessary features that add complexity and bugs to the system.

Unnecessary to you maybe but not to other people. It's a tiny bit rude to simply call a feature rude just because you don't use it. After all, by that argument I could call the screen reader software or the Speech-to-Text bloat. But they aren't.

All of those systemd features have been implemented hundreds of times as buggy hacky shell scripts launched by cron.

agreed, and more importantly it's possible to implement these scenarios with cron if they're needed. i'll take a simple building block over bloat. where does the bloat stop? i can come up with tens more scenarios that timers doesn't cover.

I had hard requirements for randomizing cronjobs plenty of times. Once you have a large number of systems it's the default rather than the exception.

In FreeBSD see the "-J" and "-j" options to cron.

Does that add a static random delay on bootup or does it randomly delay the job each time? Because for timers you can pick that for every single timer individually.

anacron has @roboot, I use it in my cron.d/

It will also run things that were scheduled to run when the server was turned off.

Yes but anacron is still a bit less powerful than timers, since I can schedule a timer to run every hour instead of once an hour plus on reboot in two very short config lines. And I don't think anacron has a concept of running things every hours not including runtime, only including runtime.

you just drop your script in /etc/cron.hourly.

That runs it once an hour not every hour, there is an important distinction there.

Please elaborate on why this might matter? I can't think of any scenarios.

It helps dispersing jobs like backups. If you have 20 servers, your backup storage is not hit by them all at the same time. Even better, because it takes into account how long it runs, if two servers hit it at the same time, the reduced performance will automatically spread the server that took longer behind the other. That scheme reduced the needed capacity in network and CPU of our backup servers a lot.

If it ran every hour, all servers would either hit the backup store at the same time or you would have to manually disperse them. Randomized Delay is great if you want to avoid this problem with short running jobs but it doesn't work well when most jobs take 10 minutes or more and the delay becomes larger than the timer's repeat interval.

So in that case, using a "run every 60 minutes" scheme is a massive advantage that reduces coordination needs.

Then you'd put that in cron.d/ something like 5 * * * * would run at 12:05, 1:05, 2:05, 3:05, etc...

And every server will have to be put on a different schedule. By running it every 60 minutes, it doesn't matter when it runs, it automatically aligns. Once you managed 200 servers, that becomes valuable and no longer manually managable ("How many servers are running backups on :05? Do I need to move some? Can I fit in one more?")

Not OP, but this page seems to have a nice writeup: https://wiki.archlinux.org/title/Systemd/Timers

Reply on news.ycombinator.com