5 ms·
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
by zaarn 5y ago
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.
- throwawayboise 5y agoCounterpoint 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.
- zaarn 5y agoMaybe 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".
- freedomben 5y agoThis 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.
- throwawayboise 5y agoThere 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.
- zaarn 5y agoUnnecessary 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.
- DarylZero 5y agoAll of those systemd features have been implemented hundreds of times as buggy hacky shell scripts launched by cron.
- waynesonfire 5y agoagreed, 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.
- goodpoint 5y agoI 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.
- ybloviator 5y agoIn FreeBSD see the "-J" and "-j" options to cron.
- zaarn 5y agoDoes 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.
- deleted 5y ago[deleted]
- pnutjam 5y agoanacron 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.
- zaarn 5y agoYes 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.
- pnutjam 5y agoyou just drop your script in /etc/cron.hourly.
- zaarn 5y agoThat runs it once an hour not every hour, there is an important distinction there.
- pnutjam 5y agoPlease elaborate on why this might matter? I can't think of any scenarios.
- zaarn 5y agoIt 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.