It gets the "one file to define the job" right but that's the only thing that it gets right.
There is no holistic view on the jobs so you can't easily say "show me last jobs that failed" and shove that into alert.
There is email on failure but only on failure so you can't also do simple "if this mail returns fail, mark check as failed, if it returns okay, mark it as okay". You can get that info from logs but you can't get the content of error message of the app from those logs...
Environmental options history is.... interesting, better to just make script that sets everything up beforehand instead of even trying to do it via cron.
From ops perspective of managing multiple servers its utter garbage. From single user perspective it kinda works but is annoying
Systemd's timers should just be [Timer] block inside the .service
The thing about cron though is this: I learned how to run crontab easily once and I've retained the knowledge of how to use it ever since. It's a piece of cake, I don't think I've ever had a cron job fail on me except for the path issue but I've always caught that on creation since I test them right after I make it.
With systemd timers, I have to look up how to write a unitfile every. single. time. and it's not a trivial 30-second lookup like every other command, it's a 5-10 minute read through every time. And even then there's weird variations on the timer unit files I don't quite understand, and most of the time it takes more than one try to get right. It fails in some bizarre ways on certain tasks due to internal systemd inconsistencies. (Like using different escape characters in different contexts, wtf?!) And I can't remember how it's set-up so I have to look it up again when I want to administer it or change something and on the whole it's just a huge PITA.
At this point, I've used systemd timers several times MORE than I have cron and I still have no idea how to write a systemd timer unit file without looking it up, and I'd have to start from scratch to write a new one.
About the only positive is that when it fails systemd reports it decently so I can follow up on it, but man, it's not worth it. I've spent a lot more time dicking with the unit files than I have debugging failed cron jobs.
Agreed. It reminds me how I recently tried to figure out why cert rotation failed, only to realize that the cron job is sending it's error messages via email to root on a system where there is no local mail server ...
It gets the "one file to define the job" right but that's the only thing that it gets right.
There is no holistic view on the jobs so you can't easily say "show me last jobs that failed" and shove that into alert.
There is email on failure but only on failure so you can't also do simple "if this mail returns fail, mark check as failed, if it returns okay, mark it as okay". You can get that info from logs but you can't get the content of error message of the app from those logs...
Environmental options history is.... interesting, better to just make script that sets everything up beforehand instead of even trying to do it via cron.
From ops perspective of managing multiple servers its utter garbage. From single user perspective it kinda works but is annoying
Systemd's timers should just be [Timer] block inside the .service