Cron

Cron ist ein wichtiger Dienst, da er die Zeitsteuerung für essentielle, automatisch ablaufende Verwaltungsaufgaben übernimmt.

Varianten

Die naive Art, Dienste zu starten, ist die folgende. Jeder Dienst ist ein Programm oder Skript, der durch eine Zeile in der Crontab zur gegebenen Uhrzeit gestartet wird.

Vorteile:

• Die crontab ist recht übersichtlich
• Man sieht leicht die zeitliche Abfolge der Jobs, wenn man die crontab gescheit sortiert

Nachteile:

• Es ist schwierig, sicherzustellen, daß voneinander abhängende Aufgaben in der richtigen Reihenfolge ausgeführt werden (man muß Sicherheits-Zeitabstände einkalkulieren)
• Es ist schwierig, die Konfiguration aller Aufgaben zu zentralisieren und rechnerunabhängige Konfigurationen zu verwenden.

Dies führt zu der Idee, jede Aufgabe in ein Skript zu verpacken, das die Konfigurationsdaten von einer zentralen Datei liest. Noch einen Schritt weiter gedacht bedeutet das, daß man alle Aufgaben, die sich unmittelbar hintereinander ausführen lassen, in einen einzigen Skript zusammenfaßt. Das sorgt für mehr Effizienz und die Einhaltung der richtigen Reihenfolge.

Dies ist die Art, wie SuSE die Zeitsteuerung handhabt.

Vor kurzem habe ich solch einen Mechanismus implementiert, allerdings noch ohne Einbeziehung einer zentralen Konfigurationsdatei. Diverse Zeilen wurden aus der Crontab von root (crontab -e) entfernt und durch folgende ersetzt:

0 0 * * * /etc/cron.daily/jobs

Das Unterverzeichnis /etc/cron.daily enthält folgende Dateien:

-rw-r--r--   1 root     root           47 Dec 13 14:46 Joblist
-rwxr-xr-x   1 root     root           77 Dec 14 08:08 account*
-rwxr-xr-x   1 root     root           73 Dec 14 08:22 chklogs*
-rwxr-xr-x   1 root     root           30 Dec 14 08:08 hwclock*
-rwxr-xr-x   1 root     root          207 Dec 14 08:07 jobs*
-rwxr-xr-x   1 root     root           25 Dec 14 08:08 killog*
-rwxr-xr-x   1 root     root          129 Dec 13 14:10 sendlog*
-rwxr-xr-x   1 root     root           47 Dec 14 08:08 smail*

listFile="`dirname $0`/Joblist"

while read job args
do
  case "${job}" in
    #* | "")
      continue
      ;;
    *)
      "`dirname $0`/$job" $args
      ;;
  esac
done < $listFile

sendlog
chklogs
killog
account
smail
#hwclock

/usr/local/lib/smail/util/checkerr

Ähnliches läßt sich natürlich auch für andere Cron-Jobs ersinnen, die entweder zu anderen Uhrzeiten, oder nur wöchentlich, monatlich oder jährlich auszuführen sind.

Noch einen Schritt weitergedacht, mit r2d2 im Hinterkopf, würde es vielleicht Sinn machen, noch ein bißchen Performance zugunsten von mehr Flexibilität zu opfern. To be continued...

Tips

• Atd verwenden. Dieser Daemon ersetzt eine Zeile wie "* * * * * atrun" in crontab, die jede Minute "atrun" startet. Das ist eine Verschwendung von Systemleistung, da jede Minute ein Prozeß gestartet wird. Atd braucht stattdessen zwar Speicher, wird aber früher oder später ausgeswappt, da er meist untätig sein dürfte.

Welcher Cron ist besser?

Vixie Cron und dcron sind sich sehr ähnlich. Ersterer ist ausgereift und hat viele Features. Letzterer verzichtet auf einige Features zugunsten von einfacherem Programmcode. Ich selbst benutze Vixie Cron aus historischen Gründen. SuSE benutzt dcron.

Es gibt eine neue Cron-Implementierung, Anacron, die besonders für Maschinen geeignet ist, die nicht rund um die Uhr laufen. Anacron sorgt dafür, daß Jobs, die einmal täglich laufen sollen, auch tatsächlich laufen, notfalls beim nächsten Booten. Es verhindert auch, daß Jobs öfter laufen, als sie sollen.