3 ms·
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.
by lloeki 3y ago
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 3y agoExactly, 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
- lloeki 3y ago> 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.
- arminiusreturns 3y agoEven 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#Introduction https://www.gnu.org/software/mcron/manual/mcron.html#Introdu...