I've been working with various Unix and Linux systems for a while, from VMS to different versions of Unix like Solaris and HP-UX, and now primarily on Ubuntu and CentOS. While I'm fairly familiar with Cron for scheduling tasks, I've encountered something new at my current job: the previous system administrator set up systemd timer tasks instead. I learned about this only informally and realized it was a replacement for Cron, running a shell script every 30 minutes. I'm curious if this practice is generally accepted and if others have tips for using systemd timers effectively, especially considering how important documentation is for maintainability.
3 Answers
Timers are considered best practice these days, though many folks still lean on cron since it's more intuitive to use. From what I've seen, systemd timers can be a bit tricky and the documentation isn't always the best. You might find it helpful to run `systemctl list-timers` to see which timers are active; that was a discovery for me when I started using them.
I think systemd timers do offer better visibility than traditional cron jobs. You can get immediate notifications if something fails or hangs, which is a big plus. Just like others mentioned, documentation is key! Adding comments will definitely help you (and future admins) understand the setup two years down the line when things get messy.
It's not surprising that systemd is being used for task scheduling; it's encouraged in many environments, particularly in the Red Hat ecosystem. Just remember to document it! It's not common knowledge, so adding a comment in the crontab to indicate that a systemd timer is being employed is helpful for anyone looking at it later. Personally, I prefer using `@reboot` for custom tasks because it's more straightforward and others can easily understand the customizations without digging too deep.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures