cron vs. systemd timers
This is from the Chapter 4 about the process control of the “UNIX and Linux System Administration Handbook” – once again systemd ripples the waters and, IMO is almost a clear winner, despite the hesitation expressed by the book authors.
systemd timers is a feature superset of cron, and rather huge one at that. Out of six systemd timer types only one(!) is a direct representation of what cron is usually in charge of: OnCalendar. (Sure, some implementation of cron are capable of meta time specificators, like @reboot, which is yet another timer type – OnBootSec – in the realm of systemd, but anyway.)
What I personally like about systemd timers are:
- Sub-minute (actually it is sub-second) precision. Sometimes it is badly needed.
- Accuracy specification with
AccuracySec. This is a cool substitute for the hackish random delay tricks for the classic cron, which is a must for large server farms managed by a CM system. ANDoperator forOnCalendartime specifications instead of cron’s traditionalOR. It was always a great mystery to me whycronhad it asORfrom the conception.- Centralized point of periodic tasks management. It’s been daunting me for ages to find the exact place a particular cron job was defined at, with the myriad of cron files and directories throughout the system (
/etc/crontab /var/cron/tabs /var/spool/cron /etc/cron.{d,daily,monthly,weekly}etc). Withsystemdit is a simplesystemctl list-timers
Sadly, quite a few things still go vague, even after a review by such a great cohort of world-famous admins:
- Zombie processes. The nature of zombie processes is described rather vaguely, they are not at all demystified.
DATA(SIZEin FreeBSD) field is hidden from thetopdisplay for a reason. This piece of data is rather useless, at least compared to theRESitem, or am I still missing something?straceusage examples could be a little more practical, because when you first try it, it is either too simple, like with tracingcp, or too complex, like with monitoringfirefox.