3 ms·
> My best practice with cron is to not use cron if possible. Absolutely. I only randomly learnt about systemd timers thanks to a comment I read here on HN onc
by traceroute66 5y ago
> My best practice with cron is to not use cron if possible.
Absolutely.
I only randomly learnt about systemd timers thanks to a comment I read here on HN once. Since that point I've never looked back, its simply awesome.
The main reason is its enabled me to remove a whole load of boilerplate from my scripts because systemd takes care of it for me.
So my scripts are now shorter, more readable, and less prone to bugs.
> Jobs don't get started if there's one already running
Yes. This was the biggest selling point for me.
On cron, I had a ton of boilerplate using all sorts of tricks to avoid the race condition of the script being run again before it had finished its prior execution.
With systemd ? Remove the boilerplate, and, erm that's it. IIRC I don't think it even needs any special lines in your systemd unit file, it Just Works (tm).
- merpkz 5y agoWell, to be fair this article touches exactly that and solution is - use flock command before your cronjob, hardly a ton of boilerplate.
- traceroute66 5y ago> use flock command before your cronjob, hardly a ton of boilerplate Let's not go there shall we. Yes I know about flock, that's what I used. But if you are writing code correctly, you still end up with boilerplate. For a start, you need to write extra code to check the error status returned from flock. And then there's the overall point I was making. My "ton of boilerplate" referred to the overall boilerplate, i.e. flock was just one element, so then consider all the other boilerplate that was required to do all the other stuff that systemd does out of the box. Frankly, its a no-brainer. Systemd wins every time.