Cron

Um unter Linux regelmäßig wiederkehrende Aufgaben ausführen zu lassen, kann man sich Crons bedienen. Cron besteht aus zwei Teilen, dem Cron-Daemon, der für das automatische Starten der definierten Programme, bzw. für das Ausführen der Befehle zuständig ist, und der Crontab, in der die Programm- und Befehlsaufrufe (die so genannten Cronjobs) definiert werden.

Installation und Konfiguration

Standardmäßig wird unter Arch crond (Dillon’s Cron) installiert. Dieser ist in dem Paket „dcron“ im Base-Repository enthalten und wird standardmäßig beim Systemstart geladen. dcron bedarf also keiner expliziten Installation. Auch muss er nicht manuell in das DAEMONS-Array gesetzt werden.

Die eigentliche Konfiguration findet innerhalb der Crontabs statt, so dass der Cron-Daemon selbst nur über sehr minimale Konfigurationsmöglichkeiten verfügt. Diese Umfassen lediglich die üblichen Daemon-spezifischen Optionen (Loglevel, Vordergrund-Modus, etc.) und die Definition der Verzeichnisse, in denen die Crontabs abgelegt werden.

Nach der Grund-Installation von Arch können ohne weitere Installation oder Konfiguration sofort Cronjobs angelegt werden.

Crontabs

In einer Crontab werden entweder systemweit oder benutzerbezogen Befehls- und Programmaufrufe definiert, die bei Eintreten der Startvoraussetzung (Zeitangabe) ausgeführt werden. Alle Ausgaben der einzelnen Cronjobs werden per System-Mail dem Benutzer zugestellt, mit dessen Rechten der Cronjob läuft.

Der Editor, mit dem die Crontabs bearbeitet werden, ist standardmäßig vi. Wenn man einen anderen Editor verwenden möchte, ist dies problemlos möglich, indem man die Variable „VISUAL“ definiert und exportiert.

In der Crontab wird je Zeile ein Cronjob definiert. Leerzeilen und Zeilen, die mit einer Raute (#) beginnen, werden ignoriert.

Ausgeführt werden Cronjobs mit der Shell „/etc/sh“. Es werden lediglich die Variablen $HOME, $USER und $SHELL gesetzt. Eigene Funktionen und Aliase werden nicht automatisch interpretiert.

Cronjobs werden immer ausgeführt, wenn der Rechner eingeschaltet ist. Der User, der den Cronjob angelegt hat, muss nicht eingeloggt sein. Wenn der Rechner zu einem Zeitpunkt ausgeschaltet ist, der für einen Cronjob definiert wurde, wird der Cronjob nicht ausgeführt (siehe unten).

Zeitnotation

Jeder Cronjob besteht am Anfang der Zeile aus fünf Zeitangaben. Dies sind in dieser Reihenfolge:

1. Minute
2. Stunde
3. Monatstag
4. Monat
5. Wochentag

Es können hier neben genauen Angaben auch Zeitspannen (Bindestrich) oder intervalle (Slash) angegeben werden. Wenn bezüglich des Tages mehrere Angaben gemacht werden, wird der Cronjob bei Erreichen eines der beiden Zeitpunkte ausgeführt. Als Wochentag „fri“ (für „Friday“, zu Deutsch: „Freitag“) und als Tag „13“ fürt den Cronjob an jedem Freitag und am jedem Dreizehnten eines Monats aus, und nicht nur an jedem Freitag, den 13.

Einige Beispiele, auszuführen ist hier immer der Befehl „command“:

# täglich um 06:40 Morgens
40 6 * * *         command

# alle zwei Stunden zu Stundenbeginn
0 */2 * * *        command

# alle zwei Stunden zwischen 23 und 07 Uhr, sowie um 08 Uhr Morgens
0 23-7/2,8 * * *   command

# täglich um 08:30, 12:30 und 16:30 Uhr
30 8,12,16 * * *   command

# um 11 Uhr morgens am Neunten eines Monats, sowie jeden
# Montag, Dienstag und Mittwoch
0 11 9 * mon-wed   command

# Jeden Montagmorgen um 9 Uhr
0 9 * * mon        command

# um 04 Uhr morgens am ersten Januar
0 4 1 jan *        command

Programmpfade

In der Crontab wird standardmäßig nur ein sehr rudimentärer Pfad gesetzt. Für viele Anwendungsfälle ist das so vollkommen ausreichend. Wenn es allerdings Programme gibt, die unänderbar auf bestimmte Programme zugreifen, und sich dabei darauf verlassen, dass die Orte der Programme im Pfad stehen, kann es zu Ausfällen führen. Aus diesem Grund sollte man vor allen Ausführ-Definitionen den Pfad definieren

PATH=$PATH:/eigener/programmpfad

PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/perlbin/site:/usr/bin/perlbin/vendor:/usr/bin/perlbin/core:/opt/qt/bin

Im ersten Beispiel wird der Cron-Standardpfad um eine eigene Definition (hier „/eigener/programmpfad“) erweitert. Pfade werden in der Pfad-Definition mittels Doppelpunkt getrennt. Im zweiten Beispiel wird der Pfad komplett durch eine eigene Definition ersetzt. Weitere Informationen über den Pfad befinden sich Wiki-Artikel Umgebungsvariablen.

Das Bearbeiten einer Crontab

Wenn man am Terminal die Crontab zum Bearbeiten öffnet, wird die Crontab nicht direkt geöffnet, sondern vom System ausgelesen, und unter einem temporären Namen abgelegt. Das System merkt sich diesen Namen und „beobachtet“ die Datei. Dann wird der eingestellte Editor mit dieser temporären Datei geöffnet.

Man bearbeitet nun diese temporäre Datei. Nach bearbeiten und speichern der Datei und dem Schließen des Editors erkennt das System, dass die Datei geändert wurde, liest sie ein, und schreibt die Einträge in der Datei zurück in die Crontab. Danach wird im Terminal-Fenster ein entsprechender Hinweis ausgegeben, dass die Crontab bearbeitet und neu erstellt wurde, oder eben, dass keine Änderungen an der Crontab vorgenommen wurden.

Die Crontab selbst liegt unter „/var/spool/cron/benutzername“ und sollte nicht direkt bearbeitet werden, zumal ein normaler User an dieser Datei auch nicht die nötigen Rechte zum bearbeiten hat.

Arten von Crontabs

Generell gibt es zwei Arten von Crontabs: benutzerbezogene und Systemweite Crontabs, bzw eine „weniger cronistische“ Möglichkeit, Cronjobs zu erstellen.

Benutzerbezogen

Um für den aktuell angemeldeten Benutzer einen Cronjob zu erstellen, bzw. die Crontab zu bearbeiten, bedient man sich des Programms „crontab“. Wenn man sich die Crontab anzeigen lassen möchte, ruft man das Programm mit dem Parameter „-l“ auf. Zum Bearbeiten der Crontab benutzt man den Parameter „-e“.

checker@machine ~ $ crontab -l
*/10 * * * *     /home/checker/checkscript.sh whattocheck
*    7 * * mon   backuptool /media/target >> /home/checker/backuplog 2>&1

In diesem Fall wird die Crontab des Users „checker“ angezeigt. Es sind zwei Cronjobs definiert. Der erste Cronjob wird im Zehn-Minuten-Takt ausgeführt, und besteht aus dem Script „/home/checker/checkscript.sh“ mit dem Parameter „whattocheck“.

Der Zweite Cronjob wird jeden Montag um sieben Uhr morgens ausgeführt und ist das Programm „backuptool“ mit dem Parameter „/media/target“. Zusätzlich wird bei diesem Cronjob die Ausgabe komplett in die Datei „/home/checker/backuplog“ umgeleitet.

Auch root verfügt über eine Crontab. In dieser Crontab befinden sich standardmäßig nur Aufrufe für weitere Cron-spezifische Funktionen. Dies sollte auch nicht geändert werden, da hiermit ein Großteil der Funktionalität verloren geht, die Cron ausmacht und dies teilweise auch systemkritische Folgen haben kann.

Systemweit

Es gibt neben der Crontabs noch vier Verzeichnisse, in denen Scripts abgelegt werden können, die dann vom Cron-Daemon entsprechend des Verzeichnisses ausgeführt werden, dabei handelt es sich um die folgenden Verzeichnisse:

• /etc/cron.daily
• /etc/cron.hourly
• /etc/cron.monthly
• /etc/cron.weekly

Die Scripts werden automatisch mit den Rechten des Users ausgeführt, mit dem der Cron-Daemon läuft, normaler Weise ist dies root. Die Scripts sind ganz normale Shellscripts. Wenn man also weiß, dass man einen Cronjob einmal wöchentlich ausführen muss, erstellt man ein Shellscript, und verschiebt/kopiert es nach „/etc/cron.weekly“. Der Cron-Daemon kümmert sich dann um die Ausführung.

Vor- und Nachteile

Zu den Vorteilen von Cron zählen die einfache Wartbarkeit, sowie die Möglichkeit, je User beliebig viele Cronjobs, die unabhängig vom Login-Status des Users laufen, definieren zu können. Durch die „/etc/cron.*“-Verzeichnisse ist es zudem sehr einfach möglich, regelmäßige Cronjobs zu erstellen.

In der Regelmäßigkeit liegt auch Crons Stärke. Anhand der vielfältigen Kombinationsmöglichkeiten bei der Definition des Ausführzeitpunktes kann man genau einplanen, wann ein Cronjob ausgeführt werden soll. Es besteht ebenfalls die Möglichkeit, dass ein Cronjob unter gewissen Umständen nicht ausgeführt soll.

Nachteilig ist, dass Cronjobs nicht ausgeführt werden, wenn der Computer nicht zu dem Zeitpunkt in Betrieb ist, zu dem ein Cronjob definiert ist, und dieser Cronjob nach Einschalten des Computers auch nicht nachträglich ausgeführt wird. Zudem ist die Syntax der Zeitangaben etwas gewöhnungsbedürftig.

Es können mit Cron zudem keine einmaligen Aufgaben ausgeführt werden (beispielsweise kann man zwar definieren, dass ein Cronjob einmal im Jahr zu einem bestimmten Zeitpunkt laufen soll, nicht aber „einmalig am 14. Oktober um 13:37 Uhr – oder sobald der Computer danach wieder eingeschaltet ist, und danach nie wieder“).

Alternative Lösungen

Neben dem klassichen Cron-System gibt es auch noch andere Möglichkeiten, Aufgaben zeitgesteuert zu starten.

Auf jeden Fall ausführen

Da Cronjobs nur ausgeführt werden, wenn der Computer zu dem definierten Zeitpunkt in Betrieb ist, kann es vorkommen, dass ein Cronjob nie ausgeführt wird. Wenn man zum Beispiel ein Backup auf 04 Uhr Nachts gelegt hat, aber zwischen 03:50 und 04:30 der Computer grundsätzlich nicht in Betrieb ist, wird das Backup nie ausgeführt.

Für Aufgaben, die auf jeden Fall ausgeführt werden sollen, kann man anacron verwenden, dies ist ein Cron-Manager, der etwas anders funktioniert, als Cron. Statt einer genauen Zeitangabe für eine Aufgabe, wird ein Zeitraum in Tagen definiert, in dem der Befehl ein Mal ausgeführt werden muss. Wenn der Zeitraum erreicht oder überschritten wurde, wird der Befehl dann ausgeführt.

anacron ist im „Community“-Repository verfügbar.

Einmalig ausführen

Will man Befehle nur einmalig ausführen, kann man hierzu at verwenden. Hier definiert man einen genauen Zeitpunkt für einen Befehl, und hat dabei vielfältige Möglichkeiten bei der Angabe der Zeit.

• „now + 20 mins“ führt den Befehl in 20 Minuten aus.
• „tomorrow -20 mins“ führt den Befehl morgen zur selben Uhrzeit abzüglich 20 Minuten aus
• „tuesday 13:37“ führt den Befehl nächsten Dienstag um 13:37 Uhr aus
• „now“ führt den Befehl sofort aus
• „tomorrow noon“ führt den Befehl am nächsten Tag mittags aus

at ist im „Extra“-Repository verfügbar. Nach der Installation muss der at-Daemon „atd“ in das DAEMONS-Array in der rc.conf eingetragen, sowie der Daemon gestartet werden.