Diener auf die Minute

Distributionschaos

Obwohl in der Kommandospalte natürlich jedes halbwegs sinnvolle Kommando stehen kann, hat es sich eingebürgert, die systemweiten Cron-Jobs etwas systematischer zu ordnen. Jede Aktion, die einmal täglich ausgeführt werden soll, wird in ein Shellskript gepackt und z. B. im Verzeichnis /etc/cron.daily (vgl. Tabelle 2) abgelegt (Ausführbarkeitsrechte nicht vergessen!), wöchentlich zu erledigende Aufgaben in /etc/cron.weekly usw.

Die globalen Verzeichnisse für Cron-Skripte haben folgenden Vorteil: Viele Programmpakete ziehen für Cron prädestinierte Aufgaben nach sich – ein News-Server möchte einmal am Tag News holen und alte Postings"auslaufen lassen", die System-Log-Utilities syslogd und klogd sollten sicher gehen können, dass Logdateien einmal die Woche gestutzt oder besser rotiert werden, etc.

Eine clevere Installationsroutine sorgt folglich dafür, dass mit der Installation auch gleich der passende Cron-Job aufgesetzt wird. Schriebe sie einfach eine Zeile in /etc/crontab, sähe es da bald sehr unübersichtlich aus, und besonders geschickt deinstalliert sich so etwas auch nicht – abgesehen davon, dass sich nicht immer alles halbwegs übersichtlich mit einer Zeile ausdrücken lässt. Also kopiert oder generiert die Installationsroutine ein nettes Shellskript, das root gegebenenfalls auch anpassen kann, und legt es im passenden Verzeichnis ab.

Leider zeigt sich an dieser Stelle das Distributionschaos ganz besonders, allerdings glätten sich die Wogen bei den Namen der Cron-Skript-Verzeichnisse in aktuellen Distributionen zum Glück etwas.

Schlimmer sieht es aus, wenn man sich anschaut, auf welche Art und Weise der Cron-Daemon dafür sorgt, dass diese Skripte zu passenden Zeiten ausgeführt werden. Oft – wie in Listing 1 zu sehen – benutzen Distributoren hier das Kommando run-parts, um alle Skripte im jeweiligen Verzeichnis abzuarbeiten. Diese Verfahrensweise wird von Debian, Red Hat und Derivaten verwendet. Caldera tanzt ein bisschen aus der Reihe, indem man statt des Binaries run-parts das Shellskript cronloop verwendet.

SuSE hingegen gefiel dieses Verzeichniskonzept lange Zeit ganz und gar nicht: Bis Version 5.3 ruft /etc/crontab hier das Skript /root/bin/cron.daily auf, das täglich die zu erledigenden distributionsspezifischen Aufgaben herunter rattert und zu guter Letzt auch noch das Skript /root/bin/daily.local für lokale Problemstellungen abarbeitet. Als sei das nicht schon unübersichtlich genug, wird zudem noch fröhlich und unsystematisch in /etc/crontab rumgewurstelt.

Ab Version 6.0 schließen die Nürnberger einen Kompromiss und legen ebenfalls besagte Directories an. Während run-parts andernorten als universell einsetzbarer, von cron unabhängiger Skriptstarter konzipiert ist, werden die in den Cron-Verzeichnissen befindlichen Skripte bei SuSE 6.0 und neuer von einem einzigen spezialisierten Skript namens /usr/lib/cron/run-crons aufgerufen.

Variabel

Doch wenden wir uns wieder Listing 1 zu: Da wären schließlich noch die mysteriösen Zeilen

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

zu erklären. Wer schon mal den Suchpfad für ausführbare Programme in der Shell geändert hat, findet hier alte Bekannte in leicht geänderter Funktion wieder: Variablen, die in der Form Variablenname=Wert angeben werden.

Mit der Umgebungsvariablen PATH legt man fest, dass ausführbare Dateien in den nach dem Gleichheitszeichen angegebenen und durch Doppelpunkt getrennten Verzeichnissen einfach nur mit ihrem Namen aufgerufen werden können. Liegt ein Programm außerhalb des Suchpfads, muss man es hingegen mit der kompletten Pfadangabe aufrufen.

Zwei ausführbare Dateien gleichen Namens kann es durchaus geben – sie müssen lediglich in verschiedenen Verzeichnissen liegen. Da der Cron-Daemon mit root-Rechten ausgestattet ist (Wie sonst sollte er imstande sein, Aufgaben mit den Berechtigungen unterschiedlicher User auszuführen?) und damit in recht gefährlichem Gebiet operiert, geht man auf Nummer sicher und gibt mit der Variable PATH in der Crontabelle explizit an, welche Verzeichnisse als Suchpfad zugelassen sind. Da das Verzeichnis /home/listar/bin im obigen Beispiel nicht in PATH stand, musste gen-archive mit kompletter Pfadangabe in die /etc/crontab geschrieben werden.

Tabelle 3 gibt einen Überblick über die wichtigsten in Cron-Tabellen benutzbaren Variablen.