Cron

Cron wird durch eine Crontab-Datei gesteuert. Dies ist eine einfache Textdatei in der neben der Zeitinformation auch die auszuführenden Shell-Befehle eingetragen sind. Dabei wird pro Zeile die Zeitinformation und daran anschließend in der gleichen Zeile das aufzurufende Programm eingetragen, üblicherweise inklusive Angabe des kompletten Pfades. Die Spaltentrennung erfolgt durch Leerzeichen. Kommentarzeilen beginnen mit dem Symbol # am Anfang einer Zeile. Die grundlegende Struktur der crontab besitzt folgenden Aufbau:

┌───────────── Minute (0 - 59)
│ ┌───────────── Stunde (0 - 23)
│ │ ┌───────────── Tag des Monats (1 - 31)
│ │ │ ┌───────────── Monat (1 - 12)
│ │ │ │ ┌───────────── Wochentag (0 - 6)
│ │ │ │ │
* * * * *  /Pfad/Programmname

Beispielsweise führt folgende Zeile in der Crontab dazu, dass das Programm /bin/prog.sh jeden Samstag (Tag = 6) um 23:45 aufgerufen wird:

# Crontab Beispiel
45 23 * * 6 /bin/prog.sh

Cron, geschrieben von Brian W. Kernighan, war in Unix Version 7 ein Systemdienst (später als Daemon), der aufgerufen wurde, wenn sich das Betriebssystem im Mehrbenutzermodus befand. Kernighans Algorithmus war einfach: Die Crontab wurde einmal in der Minute eingelesen und ausgewertet und Befehle, deren Ausführung für diese Minute geplant war, mit Root-Rechten ausgeführt.

Diese Version von Cron war einfach und robust, verbrauchte jedoch auch Ressourcen, wenn nichts zu tun war. Bei einem in den späten 1970er Jahren an der Purdue University durchgeführten Lasttest wurde festgestellt, dass die Anwendung zu viel Last auf dem System – einer VAX, die sich die Mitarbeiter teilten – erforderte.

Die nächste Version von Cron wurde mit der Veröffentlichung von Unix System V geschaffen, um die Fähigkeiten von Cron für alle Benutzer und nicht nur für den Superuser eines Unix-Systems zu erweitern. Es mag trivial erscheinen, da die meisten Unix- und Unix-ähnlichen Systeme über leistungsstarke Prozessoren und nur eine kleine Anzahl von Benutzern verfügen. Zu diesem Zeitpunkt erforderte der Einsatz auf einem 1-MIPS-System mit rund 100 Benutzerkonten einen neuen Ansatz.

In einer Ausgabe der Fachzeitschrift Communications of the ACM vom August 1977 veröffentlichten W.R. Franta und Kurt Maly einen Artikel mit dem Titel An efficient data structure for the simulation event set[1], worin sie eine Datenstruktur für Ereigniswarteschlangen für diskrete ereignisgesteuerte Simulationssysteme beschreiben, die nachweislich den am häufigsten verwendeten Algorithmen mit einfach verketteten Listen überlegen sind (“performance superior to that of commonly used simple linked list algorithms”) und eine Worst-Case-Komplexität von ${\displaystyle O\left({\sqrt {n}}\right)}$ besitzt, wobei n die Anzahl der Ereignisse in der Warteschlange bezeichnet.

Der Student Robert Brown erkannte nach Durchsicht dieses Artikels die Parallele zwischen Cron und ereignisorientierter Simulation und schuf eine Implementierung der Franta-Maly Event list manager (ELM) für Experimente. Ereignisorientierte Simulationen laufen in sogenannter „virtueller Zeit“ ab. Die anstehenden Ereignisse aus der Warteschlange werden dabei so schnell wie möglich ausgeführt und haben Auswirkungen auf die aktuelle, virtuelle Zeit des nächsten Ereignisses. Die Ausführung des Ereignissimulators in Echtzeit („real time“) trat anstelle der Ausführung mit virtueller Zeit. Diese Version des Crons verbrachte den Großteil der Zeit in Inaktivität und wurde erst dann aktiv, wenn die Ausführung der nächsten Aufgabe anfiel.

Zum Graduiertenkolleg kam 1978 u. a. der Doktorand Keith Williamson hinzu und wurde Systemmitarbeiter im Fachbereich Informatik. Als erste Aufgabe, „zum Aufwärmen“, bat Brown ihn, den Prototyp Cron zu einem Produktionsumgebungsservice weiterzuentwickeln. Dieses Mehrbenutzer-Cron ging Ende 1979 an der Purdue University in Gebrauch. Diese Version von Cron ersetzte vollständig die /etc/cron, die in der Informatik-Abteilung VAX 11/780 mit 32/V im Einsatz war.

Der Algorithmus, der für dieses Cron eingesetzt wurde, verhält sich wie folgt:

1. Beim Start des Systems nach einer Datei namens „.crontab“ in den Home-Verzeichnissen aller Kontoinhaber suchen
2. Für jedes gefundene crontab wird der nächste Zeitpunkt in der Zukunft bestimmt, an dem ein Befehl ausgeführt werden soll.
3. Platziere diese Befehle auf der Franta-Maly Event-Liste mit der entsprechenden Zeit und ihren „fünf Feld“-Zeit-Spezifikationen.
4. Tritt in die Hauptschleife ein:
   1. Suche den Eintrag an der Spitze der Warteschlange und berechne, wie weit in der Zukunft er ausgeführt werden soll.
   2. Tritt für diesen Zeitraum in Ruhezustand.
   3. Beim Erwachen und nach Überprüfung der korrekten Zeit, führe die Aufgabe an der Spitze der Warteschlange aus (im Hintergrund) mit den Rechten des Benutzers, der die Aufgabe erstellt hat.
   4. Bestimme den Zeitpunkt in der Zukunft, um den Befehl auszuführen und schreibe ihn wieder in die Event-Liste mit dem errechneten Zeitwert.

Zusätzlich reagierte der Daemon auf SIGHUP-Signale und plante halbstündlich spezielle Ereignisse zum erneuten Einlesen der Crontab ein. Ausgaben auf den Standardaus- sowie Fehlerausgaben wurden per E-Mail an den Besitzer der Crontab gesandt. Der Ressourcenverbrauch dieser Implementierung von Cron war nur noch von der Menge und Häufigkeit der geplanten Aufgaben abhängig, mit Ausnahme der Überwachung der Crontab.

Williamson schloss sein Studium ab, verließ die Universität mit einem Master of Science der Informatik, schloss sich den Bell Laboratories in Murray Hill in New Jersey an und nahm seine Fassung von Cron dorthin mit. In den Bell Laboratories integrierten er und andere den Unix-Befehl at in Cron, verschoben die Crontab-Dateien aus dem Benutzerverzeichnis in ein gemeinsames, Host-spezifisches Spool-Verzeichnis und führten ein dadurch notwendig gewordenes Kommando crontab ein, mit dem Benutzer ihre Crontab-Dateien in dieses Spool-Verzeichnis kopieren konnten.

Diese Version von Cron erschien später weitgehend unverändert in Unix System V und BSD sowie deren Derivaten, im Betriebssystem Solaris von Sun Microsystems, IRIX von Silicon Graphics, HP-UX von Hewlett-Packard sowie IBM AIX. Eigentlich hätte die Software von der Purdue Research Foundation lizenziert werden müssen, da diese die Entwicklung finanzierte, zur damaligen Zeit wurde jedoch kein Augenmerk darauf gelegt.

Mit dem Aufkommen des GNU-Projekts und Linux erschienen neue crons. Die häufigste von ihnen ist die Vixie cron, die ursprünglich von Paul Vixie 1987 geschrieben wurde. Version 3 von Vixie cron wurde Ende 1993 veröffentlicht. Version 4.1 wurde in ISC Cron umbenannt und im Januar 2004 veröffentlicht. Version 3 wird mit einigen geringfügigen Bugfixes in den meisten Linux-Distributionen und BSD verwendet.

Im Jahr 2007 entstand noch der Red-Hat-Fork von vixie-cron 4.1, das Cronie Projekt, und im Jahr 2009 anacron 2.3. Allerdings ist anacron kein unabhängiger cron-Daemon, er stützt sich zur Ausführung auf einen anderen cron-Daemon.

Weitere populäre Implementierungen sind dcron und fcron. dcron war das Werk von DragonFly BSD Gründer Matt Dillon, derzeit wird der Code von Jim Pryor gepflegt.