News for hackers. Stuff that matters.

A comment on We're migrating many of our servers from Linux to FreeBSD. Parent comment

Re:We're migrating many of our servers from Linux to FreeBSD by zaarn on Monday January 24, 2022 @12:39PM (#30060997)
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.

[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by pnutjam on Tuesday January 25, 2022 @11:25AM (#30073735)
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.

[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by zaarn on Tuesday January 25, 2022 @11:29AM (#30073791)
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.
[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by pnutjam on Tuesday January 25, 2022 @11:49AM (#30074117)
you just drop your script in /etc/cron.hourly.
[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by zaarn on Thursday January 27, 2022 @01:57AM (#30097122)
That runs it once an hour not every hour, there is an important distinction there.
[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by pnutjam on Thursday January 27, 2022 @10:38AM (#30101799)
Please elaborate on why this might matter? I can't think of any scenarios.
[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by zaarn on Thursday January 27, 2022 @11:07AM (#30102208)
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.

[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by pnutjam on Friday January 28, 2022 @01:36PM (#30118589)
Then you'd put that in cron.d/ something like 5 * * * * would run at 12:05, 1:05, 2:05, 3:05, etc...
[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by zaarn on Wednesday February 02, 2022 @02:32AM (#30174807)
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?")
[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by throwawayboise on Monday January 24, 2022 @12:52PM (#30061204)
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.
[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by zaarn on Monday January 24, 2022 @01:06PM (#30061424)
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".
[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by DarylZero on Monday January 24, 2022 @08:42PM (#30066796)
All of those systemd features have been implemented hundreds of times as buggy hacky shell scripts launched by cron.
[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by freedomben on Monday January 24, 2022 @02:26PM (#30062623)
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.
[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by throwawayboise on Monday January 24, 2022 @03:01PM (#30063151)
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.
[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by zaarn on Tuesday January 25, 2022 @11:30AM (#30073816)
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.
[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by goodpoint on Monday January 24, 2022 @06:06PM (#30065379)
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.
[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by ybloviator on Monday January 24, 2022 @07:34PM (#30066265)
In FreeBSD see the "-J" and "-j" options to cron.
[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by zaarn on Tuesday January 25, 2022 @11:31AM (#30073839)
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.
[ Parent | on HN ]
Re:We're migrating many of our servers from Linux to FreeBSD by waynesonfire on Monday January 24, 2022 @03:36PM (#30063653)
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.
[ Parent | on HN ]