Subsections

• Der Terminkalender crontab
  • Die crontab-Datei
  • Beispiele:
  • Umgebungsvariable in der crontab-Datei
  • Das crontab-Kommando

Der Batchdämon crond

    

Der vielseitigste aller Dämonen ist der crond (gesprochen cron-d). Er führt beliebige Kommandos automatisch zu vorbestimmten Zeitpunkten aus, wie nach einem Fahrplan. Einmal pro Minute sieht der Dämon in seinen Terminkalender und führt zuverlässig und pünktlich alle anstehenden Kommandos aus.

Der unter Linux verbreitete crond von Paul Vixie (vixie-cron) erlaubt prinzipiell allen Benutzerinnen, mit dem crontab-Kommando eine eigene Spalte in dem Terminkalender des Dämons einzurichten. Die in dieser Spalte eingetragenen Befehle werden dann ,,im Auftrag``, also mit der Benutzerkennung der Auftraggeberin, ausgeführt.

Wie der Druckerdämon lpd wird der crond normalerweise während der Systeminitialisierung aus einer der rc*-Dateien aufgerufen. Der Dämon geht von selbst in den Hintergrund.

Der Terminkalender des Dämons befindet sich im Verzeichnis /var/spool/cron/crontabs und besteht aus beliebig vielen Spalten, jede in Form einer Datei mit dem Namen der Auftraggeberin.

Der Terminkalender crontab

  Die einzelnen Dateien für den Terminkalender des Dämons werden von den Auftraggeberinnen verwaltet. Es handelt sich dabei um einfache ASCII-Textdateien, die beispielsweise mit dem elvis-Editor erzeugt werden können. Weil das ./crontabs-Verzeichnis des Dämons für normalsterbliche Systembenutzerinnen nicht beschreibbar ist (es ist normalerweise nicht einmal lesbar), muß eine Vorlage für die Termindatei in einem anderen, beschreibbaren Verzeichnis angelegt werden. Die Veränderung des ./crontabs-Verzeichnisses wird dann vom crontab-Kommando mit Superuser-Rechten vorgenommen.

Die crontab-Datei

In einer Termindatei werden alle Zeilen, die weder leer sind noch mit einem #-Zeichen in der ersten Spalte als Kommentar markiert sind, vom Dämon bearbeitet. Solche Zeilen können entweder eine Umgebungsvariable für die Ausführung aller in dieser Datei aufgerufenen Kommandos definieren oder eine Zeitmaske mit zugehörigen Kommando enthalten.

Eine Zeitmaske besteht aus fünf Feldern, die durch Leerzeichen voneinander getrennt werden.

Die Zeitmaske

Feldnummer 1 2 3 4 5

Bedeutung Minute Stunde Monatstag Monat Wochentag

Bereich 0-59 0-23 0-31 0-12^* 0-7^* 6r^*oder Namen

Die Monate und Wochentage können auch mit ihren englischen Namen angegeben werden. Die Namen können auf drei Zeichen abgekürzt werden, Groß-/Kleinschreibung wird ignoriert.

Bei Zahlendarstellung des Wochentages entsprechen 0 und 7 dem Sonntag.

Jedes Feld der Zeitmaske kann durch einen Asterisk `*' belegt werden, der auf jeden Termin paßt.

Die Felder können durch Komma getrennte Listen von Zeiteinträgen sowie Bereiche der Form von-bis enthalten.

In Bereichen dürfen keine Namen verwendet werden. Es können auch mehrere Bereiche aufgelistet werden. Zusätzlich können den Bereichen noch ,,Teiler`` zur Veränderung der Schrittweite nachgestellt werden.

Die restliche Zeile bis zum Zeilenende oder einem %-Zeichen wird als Kommando ausgeführt. Wenn ein %-Zeichen gefunden wird, das nicht durch einen Backslash entwertet ist, wird der Rest der Zeile als Eingabe an das Kommando geleitet.

Beispiele:

0 8-18 0 * 1-5 /usr/lib/newsbin/input/newsrun
Das newsrun-Kommando wird montags bis freitags von 8 bis 18 Uhr zu jeder vollen Stunde aufgerufen.

0 17 24 12 * echo %schoene Bescherung
Heiligabend um 17 Uhr, egal was für ein Wochentag. Die Mitteilung wird per Mail an den Auftraggeber geschickt. In diesem Beispiel wird der Mitteilungstext nicht in der Kommandozeile an das echo-Kommando übergeben, sondern in seinen Standardeingabekanal geschrieben.

0-59/5 * * * ~/bin/remind
Das remind-Kommando wird alle fünf Minuten aufgerufen, jeden Monat, jeden Tag, jede Stunde ...

0 6,10,14,18,22 * * * /usr/lib/uucp/uucico -s uucphost
Das uucico-Kommando wird täglich um 6, 10, 14, 18 und 22 Uhr auf- und damit der uucphost angerufen.

Ein bestimmter Tag kann sowohl als Monatstag als auch als Wochentag bestimmt werden. Wenn beide Felder bestimmt, also nicht durch einen Asterisk besetzt sind, werden sie durch eine logische ODER-Verknüpfung ausgewertet. Eine Warnung der Form

0 0-23 13 * fri wall %Achtung, Freitag der 13. *** FALSCH ***

würde also jeden Freitag und jeden 13. eines Monats ausgegeben.

Umgebungsvariable in der crontab-Datei

Wie bereits erwähnt, können in der crontab-Datei auch Umgebungsvariable für die Ausführung der Kommandos bestimmt werden. Die Variablen HOME, LOGNAME und SHELL werden von crond automatisch mit den Werten aus der passwd-Datei vorbelegt. Die Variable LOGNAME kann nicht verändert werden.

In der MAILTO-Variablen kann ein realer Account bestimmt werden, an den die Ausgabe der automatischen Kommandos geschickt wird. Wenn die Variable definiert, aber leer ist, geht die Ausgabe der Kommandos verloren. Wenn die Variable nicht definiert ist, wird die Ausgabe automatisch an den Eigentümer der Terminkalenderspalte gesendet.

Die Definition von Umgebungsvariablen erfolgt wie in normalen Shellscripts durch Zuweisung einer (möglicherweise leeren) Zeichenkette.

Das crontab-Kommando

Mit dem Anwenderkommando crontab werden die benutzerdefinierten Termindateien im Verzeichnis /var/spool/cron/crontabs verwaltet.

crontab erkennt folgende Optionen:

-u Benutzer

(user) legt den Benutzernamen fest, in dessen Auftrag eine Termindatei ausgeführt werden soll. Diese Option ist nur dem Superuser (root) zugänglich. Alle normalsterblichen Systembenutzer können (höchstens) ihre eigenen Termindateien bearbeiten.

-l

(list) zeigt den Inhalt der aktuellen Termindatei an.

-d

(delete) löscht die Termindatei aus dem Verzeichnis ./crontabs.

-r Datei

(replace) ersetzt die Termindatei im ./crontabs-Verzeichnis durch die angegebene.

Wenn im Verzeichnis /var/spool/cron die Datei allow existiert, kann das crontab nur von den darin aufgeführten Systembenutzern ausgeführt werden. Wenn anstelle der allow-Datei eine Datei mit dem Namen deny existiert, steht das crontab-Kommando allen Systembenutzern zur Verfügung, die NICHT darin aufgeführt sind.

Wenn keine der Dateien existiert, hängt das Verhalten von crontab von den Einstellungen bei der Compilierung ab. Entweder kann jeder das crontab-Kommando ausführen, oder nur der Superuser (root).

Wenn das ./crontabs-Verzeichnis vom crontab-Kommando verändert wird, liest der crond automatisch die neuen Daten, muß also nicht extra neu gestartet werden.