[lloeki]

Debugging and tracability is just nuts too. With a timer and a run-once service it's easy to see what happens, happened, and will happen:

systemctl status foo.timer tells you when it has last triggered and when it will triggered next, if it is still enabled.

systemctl status foo.service tells you if it has been triggered from the timer and when, or ran manually with start

I get the conceptual utter simplicity of cron in place of timer + a script in place of service but in practice systemd is much simpler and more consistent to manage.

[pnutjam]

Exactly, and there are still alot of old school "cron" users who don't touch the better "anacron" processes. I hate managing that stuff. Systemd > Anacron > Cron

[arminiusreturns]

Even worse, when I was finding "crons" run from Java apps with cron4j. I hated on SystemD a lot in the early days, and there are still many legit criticisms that don't have good answers, but I have come to appreciate it's power and usefulness very much. Writing your own units seems so much cleaner than the old way, and I say that as a everyday bash script writer/user. (example, systemd-nspawn for containerization)

PS: mcron is what I have been tinkering with and think will probably replace my systemd timers for most purposes.

https://www.gnu.org/software/mcron/manual/mcron.html#Introdu...

[lloeki]

> a lot of old school "cron" users who don't touch the better "anacron" processes

You're touching on something subtle where, like markdown, all cron look the same until they differ.