4 ms·

I like to think of systemd as a family of related projects meant to absorb all the triviality in a Linux system and push it to the mental background. I've long

I like to think of systemd as a family of related projects meant to absorb all the triviality in a Linux system and push it to the mental background. I've long since stopped caring about anacron (and meticulously managed cron job stdout and exit codes), writing init.d scripts, log rotation, and so on. PAM mount (and PAM in general) is more of the same: an unapproachable mess of various generations of junk for different purposes. This isn't coming from some Linux newcomer: I've used Linux for 20+ years starting with floppy-only 386s. That said, JSON? Pick a format and stick with it. Camel-cased ini files wasn't my first choice but consistency matters more at this point.

superkuh 7y ago
You think systemd timers have less triviality than cron jobs? That's pretty hard to take seriously. Setting up a cron job is a 1 line 10 second thing. Setting up a systemd timer means creating two 10 line config files from scratch than invoking a long system call before it starts up.
- rakoo 7y ago
  And then your cron job fails, but you don't know when, nor how. So you need to log it. And then your cron job runs again, because the first instance didn't finish in time. So you need to protect agains parallel execution. 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. And on and on and on. Systemd timers manages all this bookkeeping stuff so you can focus on one thing only: what your script needs to do.
  - 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.
  - downerending 7y ago
    All true. Yet, systemd itself can be quite mystifying when one is trying to determine why things aren't happening in the expected way.
- lazyier 7y ago
  > Setting up a cron job is a 1 line 10 second thing. Only if you don't care if it works or not. Or runs or not. Or don't care about dependencies. Stuff like 'what will happen if the NFS server my job depends on is unavailable for the 10 minutes in which my job executes'. Is it ok for a bunch of cron jobs to hit a stale nfs share and hang and then execute all at once? If any of those things matter then you have to then orchestrate a combination of logging solutions, monitoring solutions, and a bunch of extra logic to your scripts to make sure they work. This is why it's foolish for enterprises to depend on cron for anything serious and why people use complex batch management software for critical batch. Systemd timers offers a intermediate solution built into the OS.

superkuh 7y ago

You think systemd timers have less triviality than cron jobs? That's pretty hard to take seriously. Setting up a cron job is a 1 line 10 second thing. Setting up a systemd timer means creating two 10 line config files from scratch than invoking a long system call before it starts up.

rakoo 7y ago
And then your cron job fails, but you don't know when, nor how. So you need to log it. And then your cron job runs again, because the first instance didn't finish in time. So you need to protect agains parallel execution. 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. And on and on and on. Systemd timers manages all this bookkeeping stuff so you can focus on one thing only: what your script needs to do.
- 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.
- downerending 7y ago
  All true. Yet, systemd itself can be quite mystifying when one is trying to determine why things aren't happening in the expected way.
lazyier 7y ago
> Setting up a cron job is a 1 line 10 second thing. Only if you don't care if it works or not. Or runs or not. Or don't care about dependencies. Stuff like 'what will happen if the NFS server my job depends on is unavailable for the 10 minutes in which my job executes'. Is it ok for a bunch of cron jobs to hit a stale nfs share and hang and then execute all at once? If any of those things matter then you have to then orchestrate a combination of logging solutions, monitoring solutions, and a bunch of extra logic to your scripts to make sure they work. This is why it's foolish for enterprises to depend on cron for anything serious and why people use complex batch management software for critical batch. Systemd timers offers a intermediate solution built into the OS.