4 ms·

> And then your cron job fails, but you don't know when, nor how. So you need to log it. Which it already does. Success on Unix/Linux is silent and any output

by zrm 7y ago

> And then your cron job fails, but you don't know when, nor how. So you need to log it. Which it already does. Success on Unix/Linux is silent and any output from a cron job gets emailed by default. > And then your cron job runs again, because the first instance didn't finish in time. So you need to protect agains parallel execution. So you use flock(1) with --timeout equal to the launch interval. Assuming parallel execution is actually undesired; maybe you want it. Suppose you have a job to gzip the day's data, and if it takes 30 hours to do it, you still want to run tomorrow's job on time because tomorrow's job is running on a different day's data. > And then your cron job doesn't run, because your machine was off when it was supposed to. So you need to track when it was supposed to run, and run it. What do you propose to do instead if the machine is powered off? If it's supposed to run once a day and the machine is unplugged for three days, should it immediately run three times as soon as you turn it back on? Should it run once, but then run again only an hour later at the time scheduled for today, thereby still running twice in the same day? If the launch arguments take today's date, which day do you pass? You still have to specify what you want one way or another. It's not clear how specifying it in a shell script is any worse than specifying it in a unit file, and it can certainly be better, because arbitrary code can solve arbitrary problems. Unit files are limited to specific directives unless you want to rely on unit files calling shell scripts, and in that case why do I want to write a unit file and a shell script instead of only writing a shell script?

rakoo 7y ago
Everything can be written using shell scripts. Even cron can be written using shell scripts if you want to. But you still use cron because it provides some facility for you and you can focus more on what you want to do. It's the same for systemctl timers: for the most common cases it will give you good enough customization, because that's what you want, along with proper logging.
- zrm 7y ago
  You use cron because it does one thing and that's the thing you want to do, so it's easier to use what exists than to reinvent the wheel. The flaw in systemd is that it doesn't do one thing, it tries to do everything. Instead of launching tasks with cron, logging errors with syslog, preventing parallel execution with flock etc., systemd tries to do all of that. Worse, it assumes that once you use it for anything you'll use it for everything, so if any piece of it is unsuitable it's not as easy to swap out only the unsuitable bit for an alternative. The result is that the things it was specifically designed for are easy, but they were pretty easy already, meanwhile the things it wasn't specifically designed for become significantly more convoluted than they used to be.

by zrm 7y ago

rakoo 7y ago

Everything can be written using shell scripts. Even cron can be written using shell scripts if you want to. But you still use cron because it provides some facility for you and you can focus more on what you want to do. It's the same for systemctl timers: for the most common cases it will give you good enough customization, because that's what you want, along with proper logging.

zrm 7y ago
You use cron because it does one thing and that's the thing you want to do, so it's easier to use what exists than to reinvent the wheel. The flaw in systemd is that it doesn't do one thing, it tries to do everything. Instead of launching tasks with cron, logging errors with syslog, preventing parallel execution with flock etc., systemd tries to do all of that. Worse, it assumes that once you use it for anything you'll use it for everything, so if any piece of it is unsuitable it's not as easy to swap out only the unsuitable bit for an alternative. The result is that the things it was specifically designed for are easy, but they were pretty easy already, meanwhile the things it wasn't specifically designed for become significantly more convoluted than they used to be.