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. AND
operator forOnCalendar
time specifications instead of cron’s traditionalOR
. It was always a great mystery to me whycron
had it asOR
from 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). Withsystemd
it 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
(SIZE
in FreeBSD) field is hidden from thetop
display for a reason. This piece of data is rather useless, at least compared to theRES
item, or am I still missing something?strace
usage 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
.