Zeit und zeitgesteuerte Abläufe

Das magische Jahr 2000 entpuppte sich für die Informatikbranche als wahre Goldgrube. Viel zu spät hatten die Betreiber von Datenbanken die wahre Dimension des Problems »Jahrtausendwechsel« begriffen. Die Folge war eine fieberhafte Reaktivierung schon längst in Rente gegangener Programmierer, die die eigentlich schon als historisch einzustufenden COBOL-Quellen (u.a. Programmiersprachen) nach Datumsfeldern durchforsteten und diese von 2 Stellen auf 4 aufblähten. Jeder Entwickler weiß, was es heißt, aus tausenden Zeilen undokumentiertem Quellcode die relevanten Passagen zu extrahieren...

Linux selbst ließ dieses »Zeitproblem« relativ ruhig, da es, wie alle Unix-Systeme, für die Zeitzählung einen 32 Bit langen Zähler verwendet, der, am 01.01.1970 gestartet, erst im Jahre 2038 überlaufen wird. Bis dahin, so hofft man, wird der 32 Bit Rechner nur noch als Museumsstück überleben, und die dann verbreitete 64 Bit Zählung sollte bis »in alle Ewigkeit« reichen. Das J2K-Problem betraf also höchstens die Anwendungen unter Unix und auch hier, so lehrte die Vergangenheit, hat es keine nennenswerten Effekte gegeben.

Dennoch ist, zumindest für einen vernetzten Recher, die korrekte Zeit das A und O eines funktionierenden Systems.

Die Telefonkosten purzeln weiter, so spielt es in den heutigen Tagen nicht mehr die entscheidende Rolle, den Download des großen Datenpaketes zum billigsten Tagestarif anzuschieben. Oder doch? Oft ist das Netz tagsüber hoffnungslos überlastet, so dass sich die Übertragungsrate der Daten bei Null einpendelt. Also doch besser in den frühen Morgenstunden den FTP-Server kontaktieren!

Aber wer steht schon gern mitten in der Nacht auf? Da lässt man das System doch lieber selbsttätig die Arbeit verrichten. Weitere Beispiele für zeitgesteuerte Arbeiten lassen sich beliebig angeben und im folgenden Abschnitt werden solche auch genannt sein. Neben der Handhabung der zeitgesteuerten Abläufe, soll auch das Stellen der Systemzeit Thema dieses Textes sein.

Zuvor noch die Erläuterung zweier Begriffe: Die so genannte Hardware-Zeit ist die Zeit, die im BIOS des Rechners gespeichert ist. Sie ist batteriegepuffert und läuft auch weiter, wenn der Computer ausgeschaltet ist. Im Normalfall handelt es sich hierbei um die lokale Zeit des Standorts und leider ist es auch die Norm, dass diese Zeit - dank fernöstlicher Billigquarze - einer permanenten Gangungenauigkeit unterliegt. Die Systemzeit ist letztlich die Zeit, die Linux für seine Arbeit verwendet. Beim Systemstart wird sie anhand der Hardware-Uhr gesetzt und ggf. nach verschiedenen Methoden korregiert. Einige Werkzeuge setzen nur die Systemzeit, diese hat aber keinen Einfluss auf die Zeit im BIOS!

Eine Beschreibung zur Anwendung von at und seiner verwandten Kommandos atq atrm und batch finden Sie im Abschnitt Weiteres des Kapitels »Nutzerkommando«. Wir beschränken uns hier auf die administrativen Aspekte.

Start des Dämonen

Für die Bearbeitung der Jobs ist der at-Dämon atd verantwortlich, der bereits während des Systemstarts aktiviert werden sollte. Mit Hilfe des Kommandos ps sollte ein Zeichen des Geistes zu erhalten sein:

Fehlt eine den Dämonen betreffende Zeile, kann dieser von Hand gestartet werden. Die interessanten Optionen sind hierbei -l Auslastungsfaktor und -b Sekunden. Der atd ist so ausgelegt, dass er einen Auftrag nur zur vereinbarten Zeit startet, wenn die Systemauslastung einen bestimmten Wert (0.8) unterschritten hat. Ist das System zu diesem Zeitpunkt zu beschäftigt, stellt der atd den Auftrag solange zurück, bis der Lastwert unter die Schranke gefallen ist. Mit ersterer Option kann ein anderer als der voreingestellte Wert vereinbart werden, dies ist bei Mehrprozessorsystemen zu empfehlen. Die momentane Auslastung ermittelt der Dämon anhand der Datei »/proc/loadavg«. Mit der zweiten genannten Option kann das Zeitintervall variiert werden, indem der atd die Auftragswarteschlangen nach fälligen Jobs durchsucht. Voreinstellung ist 60 Sekunden.

Um den Dämonen schließlich nicht immer von Hand starten zu müssen, sollten Sie einen Link in allen Runleveln auf ein entsprechendes Skript anlegen. Bei den meisten Distributionen sollte das Skript »at« heißen und im Verzeichnis unterhalb der Runlevel liegen.

Zugangskontrolle

Der Zugang zum Dienst kann vom Systemverwalter eingeschränkt werden, in dem er die Benutzerkennzeichen in einer der Dateien »/etc/at.allow« oder »/etc/at.deny« aufnimmt. Dabei wird die zweite Datei nur ausgewertet, falls erstere fehlt. In »at.allow« trägt Root genau die Benutzer ein, die den Dienst beanspruchen dürfen. Nichterwähnte Benutzer werden somit ausgeschlossen. Sollen jedoch nur einige wenige Personen ausgenommen werden, so ist es einfacher, diese in der Datei »at.deny« einzutragen. Alle dort nicht benannten Benutzer haben dann Zugriff auf at. Existiert keine Datei, ist der Dienst für jeden nutzbar.

Schon die Standardinstallation von Linux birgt für manchen Benutzer Überraschungen. Da fährt man nichtsahnend sein System hoch, freut sich auf eine gute Performance und wundert sich, dass die CPU am Limit kreiselt, obwohl man doch nur seine Mails begutachtet. Geht man der Ursache auf den Grund, findet man heraus, dass »nobody« das Kommando »find« ausführt und sämtliche Ressourcen zu verschlingen scheint. Wer ist dieser »nobody«? Und wie kommt er dazu, meinen Dateibaum zu durchstöbern?

Erst einmal sei der Leser beruhigt; in jenem Fall ist es unwahrscheinlich, dass sich hinter »nobody« ein arglister Eindringling verbirgt. Hier ist vermutlich irgendein Systemprogramm am werkeln, das irgendeine Datenbank aktualisiert.

Und wer rief das Programm? Mit ziemlicher Sicherheit identifiziert man den cron als den Übeltäter. Und »Übeltäter« ist für diesen Pünklichkeitsfanatiker sicher die unpassendste Bezeichnung, er verrichtet schließlich nur gewissenhaft die ihm angetragenen Aufgaben.

Beim cron handelt es sich um einen Dämonen, auch wenn sein Name nicht mit dem sonst üblichen »d« endet. Warum dieser Name? Wer weiß... schieben wir es seinem Entwickler Paul Vixie in die Schuhe. Dieser cron sollte schon während des Systemstarts aktiviert werden. Fortan wird er minütlich zum Leben erwachen und in seinen Terminkalendern nachschlagen, ob etwas zu erledigen ist. Wenn nicht, versetzt er sich für eine weitere Minute in den Schlaf.

Der Start des Dämonen

In den meisten Fällen sollte nach der Linuxinstallation der Dämon bereits mit dem Start des Systems aktiv werden. Die verschiedenen Distributionen regeln das über ein Skript, das in allen Runleveln gestartet wird. Debian speichert das Skript unter »/etc/init.d/cron«, bei RedHat liegt es als »/etc/rc.d/init.d/cron« auf der Platte und SuSE hält »/sbin/init.d/cron« für das richtige Konzept. Sollte bei Ihnen der cron nicht aktiv sein, so überprüfen Sie, ob in den jeweiligen Runlevel-Verzeichnissen ein Link auf das Skript existiert.

Mit »/usr/sbin/cron« vermag der Systemadministrator den Dämon von Hand ins Leben zu berufen, da dessen Arbeit allerdings von unschätzbarem Nutzen ist, sollten ggf. die fehlenden Links erzeugt werden. Als Linknamen bieten sich »S21cron« für das Startskript und »K19cron« für das Stoppskript an. Wo sich die Runlevel-Verzeichnisse befinden und was es mit der Namensgebung auf sich hat, ist Thema des Abschnitts Bootvorgang.

Mehrere Terminkalender

Ist der Geist erst einmal losgelassen, so schaut er als erstes in der Datei »/etc/crontab« nach, welchen Spuk er im System als nächstes zu treiben hat. Und beim weiteren Vorgehen scheiden sich die Geister... Hier treiben die verschiedenen Distributionen allerlei eigenen »Unsinn« und kompilieren die verschiedensten Suchpfade in den Code des Dämons ein.
Entsprechend den Richtlinien des Filesystem Hierarchie Standards sollten die benutzereigenen Tabellen im Verzeichnis »/var/spool/cron« angesiedelt sein, bei Debian und RedHat findet man sie unter »/var/spool/cron/crontabs« und SuSE liegt mit »/var/cron/tabs« völlig daneben. Die letzten Dateien, die zum üblichen Auftragsvolumen des cron gehören, sind »cron.hourly«, »cron.daily«, »cron.monthly« und »cron.weekly«, die distributionsabhängig entweder unterhalb von »/etc/cron.d« oder direkt in »/etc« (SuSE) liegen.

Zu bemerken ist, dass die Dateien nicht existieren müssen, da alle Aufträge für den Dämon auch in einer einzigen Datei enthalten sein könnten. Und außerdem sind die zu überwachenden Dateien und Pfade durch Herumspielen im Quellcode beliebig anpassbar.

Der Eine darf, der Andere nicht...

Dem Systemadministrator steht es frei, bestimmte Benutzer von den Diensten des cron auszuschließen. Hierzu kann er die Benutzerkennzeichen in die Dateien »allow« und »deny« aufnehmen. Jeder Benutzer, der in der allow-Datei enthalten ist (ein Benutzer je Zeile), darf eine eigene »crontab« anlegen. Im Falle einer leeren Datei »allow« kann also niemand den cron benutzen. Existiert die »allow«-Datei nicht, kommt »deny« ins Spiel. Sie enthält genau jene Benutzer, denen der Dienst versagt wird.

allow und deny sind hier nur beispielhafte Bezeichnungen für die Dateien. SuSE und Debian benennen sie tatsächlich so, im ersten Fall liegen sie im Verzeichnis »/var/cron« und bei Debian unter »/var/spool/cron«. RedHat regelt den Zugriff über die beiden Dateien »/etc/cron.allow« und »/etc/cron.deny«.

Eine Zeile, die nicht mit dem Doppelkreuz (»#« - Kommentar) beginnt, ist entweder eine Variablenzuweisung oder eine Anweisung der Art: »Starte das Kommando zur dieser Zeit an diesem Datum«. Jede Zeile entspricht einem Eintrag, d.h. eine Anweisung oder Variablenzuweisung darf sich nicht über mehrere Zeilen erstrecken. Auch ist die Zeile auf 1024 Zeichen begrenzt. Beginnt eine Anweisungszeile mit einem Minus »-«, so wird kein syslog-Eintrag zur Protokollierung des Kommandostarts vorgenommen.

Eine Variablenzuweisung legt Umgebungsvariablen für den cron neu fest. So lassen sich dem Dämon mit PATH alternative Pfade angeben, wo er die Kommandos zu suchen hat. Mit SHELL kann eine von der »/bin/sh« abweichende Shell zur Kommandoausführung benannt werden und mit MAILTO ist es möglich, die Ausgabe, die der cron per Mail an den Eigentümer der »crontab« ausliefert, einem anderen Benutzer zukommen zu lassen (oder gar zu unterdrücken »MAILTO=«).

Eine Anweisung besteht aus 7 Feldern (in den privaten Tabellen nur 6), wobei diese durch Leerzeichen oder Tabulatoren getrennt sind. Die ersten 5 Felder betreffen die Angabe des Zeitpunkts, wann das Kommando zu starten ist:

Feld 1: Minute

0-59

Feld 2: Stunde

0-23

Feld 3: Tag

0-31

Feld 4: Monat

0-12, jan, feb, ..., dec

Feld 5: Wochentag

0-7, sun (entspricht 0 oder 7), mon, ..., sat

Jedes Feld erlaubt auch die Eingabe mehrerer Werte. Die nachfolgende Tabelle fasst die verschiedenen Syntaxvarianten zusammen, die Beispiele beziehen sich auf Minuten:

	Syntax	Beispiel/Bemerkung
Voller Bereich	*	0, 1, 2, ..., 59
Ausgewählter Bereich	1-5	1, 2, 3, 4, 5
Liste	2,3,11,12	Nur an den angegebenen Werten
Liste	2,3,30-40	Kombination aus Liste und Bereich
Schrittweite	*/2	aller zwei Minuten (0, 2, ..., 58)

Tag, Wochentag und Monat können auch als englische Namen (die ersten drei Buchstaben) angegeben werden. Klein- und Großschreibung werden dabei nicht unterschieden. Bereiche sind bei der Verwendung von Namen nicht erlaubt.

Die Datei »/etc/crontab« enthält nun als 6. Feld den Benutzer, in dessen Auftrag das Programm auszuführen ist. Bei allen anderen Tabellen entfällt der Eintrag, da die enthaltenen Kommandos immer mit den Rechten des Eigentümers der Datei gestartet werden.

Das letzte Feld beinhaltet in jeder »crontab« das auszuführende Kommando. Ein Prozentzeichen »%« kann benutzt werden, um einen Zeilenumbruch zu simulieren, alle folgenden Daten werden dem Kommando als Argumente übergeben.

Bei all der Pingelichkeit mit der Sicherheit in einem Unix-System wird sich niemand darüber wundern, dass Otto-Normalverbraucher seine cron-Jobs nicht direkt in das entsprechende Spoolverzeichnis schreiben kann. Aus diesem Grund steht ihm das Kommando crontab zur Verfügung.

Dem Systemadministrator steht es zu, die nachfolgenden Optionen mit -u Benutzer zu koppeln und somit die Datei eines beliebigen Benutzers zu bearbeiten. Die simplen Optionen sind -l zur Anzeige des Inhalts seiner eigenen Tabelle und -r zum Löschen jener. Zum Editieren der Datei ist das Kommando mit der Option -e zu starten. Kommt jetzt die Ausgabe:

...so trete man seinem Systemadministrator entgegen und frage ihn, warum man von der Benutzung des Dienstes ausgeschlossen wurde.

Gesetzt den Fall, der Aufruf glückte, so findet man sich in einem Editor wieder. Welcher das ist, steht in den Shellvariablen $VISUAL und $EDITOR (nur wenn erstere nicht gesetzt ist, wird die 2. ausgewertet) und kann nach persönlichen Wünschen angepasst werden. Übrigens scheitert ein Kommandoaufruf auch, wenn die Variable nicht oder auf einen nicht installierten Editor gesetzt ist.

Beispiel: Einmal pro Woche (Mittwoch) sollten wir ein Backup unseres Heimatverzeichnisses in Erwägung ziehen. Wir archivieren also alle Dateien und schicken das Archiv per Mail an eine Adresse. Zusätzlich soll die normale Nachricht über die erfolgte Ausführung des Kommandos unterdrückt werden.

Nach dem Abspeichern der Datei meldet crontab entweder den Vollzug »crontab: installing new crontab« oder aber einen aufgetretenen Fehler. Wir provozieren einen solchen, indem wir einen Zeilenumbruch angeben:

crontab weist uns auf die mögliche Fehlerursache hin (Zeile 2:bad minute). Klar, dass »abend« keine gültige Minutenangabe ist. Weiterhin verweigert das Kommando das Abspeichern der Datei und bietet ein erneutes Bearbeiten an. Durch Eingabe von »y« gelangen wir zurück zum Editor.

Die Verwendung des Kommandos zur Anzeige der Systemzeit wurde bereits im Abschnitt Weiteres zu Nutzerkommandos demonstriert, jetzt stellen wir Ihnen die Möglichkeiten zum Stellen der Uhr vor.

Dem Systemverwalter stehen zwei Varianten zur Eingabe der neuen Systemzeit zur Verfügung. Als erstes kann er die Zeit als einzige Zahl angeben, wobei die Reihenfolge der Ziffern wie folgt festgeschrieben ist:

Die drei ersten Angaben sind verbindlich, die weiteren werden, sodenn sie fehlen, durch die aktuellen Einstellungen ersetzt. Möchten Sie die Sekunden neu einstellen, so ist die Angabe der Jahreszahl mit vier Stellen erforderlich. Wählen Sie aus den 3 optionalen Parametern nur einen aus, wird dieser als Jahreszahl des aktuellen Jahrhunderts interpretiert.

Etwas verständlicher ist da die Verwendung eines Formatstrings, so wie es die Option -s ermöglicht. Welche Platzhalter enthalten sein können, wurde bereits im Abschnitt Weiteres zu Nutzerkommandos vorgestellt. Der folgende Aufruf setzt die Zeit wie im letzten Beispiel beschrieben:

Warum gleich die ganze Eingabe vornehmen, wenn man die Uhr nur um ein paar Minütchen korregieren will? Hier kann das Schlüsselwort now, gefolgt von der Zeitspanne um die die Uhr vorgestellt werden soll, eingesetzt werden. Um bspw. die Systemzeit um 20 Minuten vor zu stellen, nützt diese Eingabe:

Um nach obigem Vorgehen die Zeit zurückzustellen, ist dem Formatstring das Schlüsselwort ago nachzustellen:

Um Missverständnissen vorzubeugen: Unter Linux sind die beiden Kommandos clock und hwclock identisch, d.h. das Programm selbst ist »hwclock« und »clock« ist als Link auf dieses realisiert.

Mit hwclock lässt sich die Hardwareuhr auslesen und setzen. Das Kommando vermag sowohl die Systemzeit der Hardwarezeit anzupassen als auch umgekehrt, außerdem ermöglicht es mit Hilfe der Datei /etc/adjtime eine »automatische« Zeitkorrektur.

Die Option --show zeigt die lokale Hardwarezeit des Rechners an. Wird zusätzlich die Option --utc gewählt, handelt es sich um die Standardweltzeit (wenn die Hardwareuhr nach letzterer läuft, sind die beiden Angaben identisch):

Um die Systemzeit nach der Hardwareuhr zu stellen, ist die Option --hctosys zu benutzen. Gleichzeitig wird ggf. die Zeitzone angepasst. Die entgegen gesetzte Richtung ermöglicht die Option --systohc, d.h. das Stellen der Hardwareuhr nach der Systemzeit.

Mit der Option --set kann eine beliebige gültige Zeit eingestellt werden. Die Option verlangt einen Formatstring, der mittels --date="Zeit" anzugeben ist. Die Syntax der Zeichenkette entspricht dabei der des Kommandos »date -s Zeit«. Um die Hardwareuhr 23 Stunden in die Zukunft zu versetzen, gibt man z.B. Folgendes ein:

Einige Parameter von hwclock sind architekturabhängig und sie werden eher selten benötigt. Abschließend soll die Option --debug genannt sein, die bei der Fehlersuche recht hilfreich sein kann:

Auch wenn die ständige Abweichung der Hardwareuhr sehr unbefriedigend ist, so ist ihr doch etwas Gutes abzugewinnen: Sie ist relativ konstant, d.h. wenn die Uhr an einem Tag um 2 Sekunden vorgeht, dann eilt sie der realen Zeit in einer Woche um 14 Sekunden und in einem Jahr (kein Schaltjahr) um 12 Minuten und 10 Sekunden voraus.

Es liegt also nahe, diese kalkulierbare Größe zur automatischen Zeitkorrektur zu verwenden. Welche Informationen muss man kennen? Zum einen die tägliche Abweichung und zum anderen den Zeitpunkt der letzten Korrektur. Beide Werte u.a.m. stehen in der Datei /etc/adjtime.

Sie wissen hoffentlich, wie man die Zeit in einem für Maschinen verständlichen Format angibt? Nein? Dann können Sie sich glücklich schätzen, dass eine manuelle Bearbeitung der Datei /etc/adjtime nicht notwendig ist. Vollziehen Sie einfach folgende Schritte:

Thematisch gehört dieser Punkt in den Bereich des Netzwerks, aber wegen der Einfachheit sei er dem Abschnitt über die Zeit angegliedert.

Bei einem einzelnen Rechner spielt es letztlich keine entscheidende Rolle, wie exakt die Hardwareuhr tickt. Der Benutzer wird die auf seinem Desktop eingeblendete Uhrzeit anhand seiner Erfahrungen auf die korrekte Zeit interpolieren.

Bei der Anbindung an ein Netzwerk sieht es schon anders aus... Sendet man eine Mail über den lokalen Maildämon, so erhält die ausgehende Nachricht die aktuelle Systemzeit als Stempel. Beim Empfnger heißt das, dass die Mail in die Empfangsliste gemäß ihres Sendedatums eingeordnet wird (die meisten Benutzer ordnen die Nachrichten nach dem Datum). Angenommen, die lokale Systemzeit hinkt der realen Zeit drastisch hinterher, so kann die Mail in der Anzeige zwischen den »alten« Nachrichten »untergehen«.
Viel drastischer äußert sich das Problem, wenn eine Datei von verschiedenen Leuten an verschiedenen Orten bearbeitet wird. Womöglich wird eine alte Version für die aktuellere gehalten, nur weil deren Zeitstempel dies nahe legt. Und das, weil die Uhr des einen Rechners ein »paar« Stunden voraus eilte...

In einem Netzwerk also ist der Wunsch nach Synchronisation der einzelnen Rechner untereinander wesentlich ausgeprägter als an der heimischen Spielekonsole. Die Lösung liegt im Einrichten eines Zeitservers, also eines Rechners, dessen Zeit als aktuell angesehen wird (z.B. weil er eine Funkuhr besitzt) und dem periodischen Abgleich der Zeiten zwischen Server und Clients.

Einen Zeitserver einrichten

Wie schon angedeutet, handelt es sich hierbei um die Konfiguration eines Netzwerkdienstes. Wenn Sie einige Schritte nicht verstehen sollten, so informieren Sie sich in den Netzwerkkapiteln.

Als erster Schritt sind die entsprechenden Dienste zu aktivieren. Hierzu sind in der Datei /etc/inetd.conf folgende 4 Zeilen zu entkommentieren (das Doppelkreuz am Beginn der Zeilen ist zu entfernen):

Die Clients

Um den Vorgang z.B. bei jedem Rechnerstart automatisch auszuführen, könnten Sie die Befehle in ein kleines Skript fassen und dieses an entsprechender Stelle des Bootvorgangs automatisch starten lassen.

Hinweis: Im Internet existieren eine Reihe frei zugänglicher Zeitserver (z.B. wrzx03.rz.uni-wuerzburg.de), die Sie zum Abgleich ihres eigenen Zeitservers verwenden können (falls dessen Uhr nicht richtig tickt).