Not that I have a problem with systemd, which I don't hate and I use extensively (both in my customers' products and on my machine because it's the default init system of the distro I use), but this thread illustrates a lot of why a lot of pre-systemd Linux users just don't dig it.
Every time someone asks "why should I use systemd instead of cron" they get these (technically correct -- the best kind of correct!) answers about how systemd timers allow you to attach jobs to cgroups, define dependencies, test unit files separately vs. changing crontabs for 1 minute ahead (which I don't think is a "cron idiom" -- I've certainly never done i -- but we all have our weird hacks), and how it has built-in jitter options and per-job environment settings and whatnot.
These are all very relevant for real-life workloads of super advanced cloud systems, I'm sure. (Which I'm not saying in a derogatory way. I haven't written back-end code in like 12 years now, the things that are happening there today blow my mind. I know these are complex systems so I'm pretty sure they have complex problems which have complex solutions.)
But guys, I just need to run a bash script every day at 2 AM. 99% of us just need to run a bash script every day at 2 AM. This has worked reliably in cron since practically forever. I have grumpily learned the new way of doing it but I can't really justify the time I've put into it, nor the (very extensive) troubleshooting that was involved in it. I just woke up one morning and sat down in front of a Linux machine and I found out that there's a new way to run things at 2 AM.
If you want to woo me with cool systemd-timers features, tell me that it finally has an equivalent to cron's MAILTO, so that I don't have to write yet another systemd unit file that wraps a script written by me if I want to get a notification when a job has failed, because somehow that hasn't made its way into the "everything but the kitchen sink" list which otherwise includes things like attaching jobs to cgroups.
I suppose it would be quite nice to have a MailTo= directive in a service. When the service stops, systemd could retrieve whatever it logged to the journal and mail it to the specified address.
Until such a feature is implemented, you could try:
ExecStart=/bin/bash -c 'shopt -o pipefail; mycommand | mail -s foo@example.com'
Certainly not as convenient as MailTo=, but a lot less complicated than using OnFailure= with a separate service that tries to mail you the output.
Huh. I never thought of that, although it was so damn obvious (I feel twice as stupid now that I realize I do a version of that on my machine, albeit not in order to send mail). I guess that's what I get for going all "Arch Wiki will you please just show me how you kids are doing it today and leave me be" on it.
But to be honest, not having to do <shell> -c <exec this or send me an email> ever again is one of the reasons why we're doing the whole systemd thing, and one of its big promises. If it comes to writing shell mantras again, I might as well use vixie cron (or one of its descendants) and benefit from 30+ years of bugfixes across more Unices than I can name, plus the acquired wisdom of the Interwebs.
Edit: plus... does this still allow you to get the other goodies, like being able to specify environment variables for a specific job?
Not sure I follow about the environment variables.
As for 'exec this or send me an email' -- I would also much prefer to see this be done by systemd itself. Fortunately bash's 'pipefail' feature plus bsd-mailx's '-s' flag make this reasonably quick and sane; I wouldn't even bother to attempt it if I were stuck with POSIX sh or if the mail command lacked the logic to not send the mail if stdin is empty.
Try systemd-cron https://github.com/systemd-cron/systemd-cron. Best of both worlds: simplicity of crontab and manageability of systemd. And it comes with built-in MAILTO support.
One more thing systemd tries to take over. Do not want.
Instead, try GNU mcron (guile-based).
"The mcron program represents a complete re-think of the cron concept originally found in the Berkeley and AT&T unices, and subsequently rationalized by Paul Vixie. The original idea was to have a daemon that wakes up every minute, scans a set of files under a special directory, and determines from those files if any shell commands should be executed in this minute.
The new idea is to read the required command instructions, work out which command needs to be executed next, and then sleep until the inferred time has arrived. On waking the commands are run, and the time of the next command is computed. Furthermore, the specifications are written in scheme, allowing at the same time simple command execution instructions and very much more flexible ones to be composed than the original Vixie format. This has several useful advantages over the original idea. (Changes to user crontabs are signalled directly to mcron by the crontab program; cron must still scan the /etc/crontab file once every minute, although use of this file is highly discouraged and this behaviour can be turned off). "
The cron syntax is used by a bunch of other things as well, e.g k8s cronjobs so sites like this are still useful even if you aren't using a traditional cron
Define a unit and run it individually to troubleshoot vs modifying the crontab for 1 min ahead
Logging in journalctl
Built in jitter options to spread tasks across a window in a large fleet
Ability to use the unit as a dep for other things
Instrumented in systemctl list-timers
Store config in user home dir (I think ) for tasks owned by a user
These aren’t really better, they are just different ways of doing things the old fashioned way.
(e.g. put all your logic in one script, test it with “env -“, lock exclusively with flock if you need it, or whatever else you have to hand in your language of choice.)
A nice feature of Systemd timers is the ability to say something like "run once per 24 hour period, but I don't care when". The task runs at a random time during the period, which is nice for tasks that hit network services, since you don't get a zillion clients hitting the server at the same time. (i.e. local midnight or UTC midnight.)
Package repo updates and Let's Encrypt renewals are a couple services I've seen use this. There isn't a great way to do this with cron that I know of, besides running some script that sleeps for a random duration.
That said, I still use cron for things that don't need this feature because it's portable and I'm just more familiar with it.
I think both have their use cases. For quick and dirty things (like manual logging/system performance), cron works just fine and is quicker to set up. For tasks that require dependencies or have to happen at very specific points in time (like immediately after the network services are started), systemd is more suited to the task.
There are of course quite a few people who dislike systemd for justifiable reasons (but I doubt it receives the disdain that SELinux does), here's a starting point:
That said, I very much like systemd and I hope it isn't going anywhere. I think it's improved on a lot of things from the SysVinit days and I hope and believe that its shortcomings will be addressed and improved in the future.
My problem with cron for short tasks is that pretty often I forget to add logging and/or locking. And then machine runs out of resources because of all the parallel jobs, and there aren’t even any logs.
