Cron-Ausgaben erfassen

Einführung

Cron-Jobs laufen im Hintergrund und sind von jeder Terminalsitzung getrennt. Das ist ideal für die Automatisierung, erschwert aber die Fehlersuche: Wenn ein Skript fehlschlägt, sehen Sie die Fehlermeldung nicht auf Ihrem Bildschirm.

Wenn ein Cron-Job eine Ausgabe erzeugt, versucht das System traditionell, diese per E-Mail an den Benutzer zu senden. Auf vielen modernen Servern, in Containern oder in Trainingsumgebungen ist der E-Mail-Versand jedoch nicht konfiguriert. Ohne eigene Umleitung kann die Ausgabe daher praktisch verschwinden.

Das ist ein Grund, warum Cron für Anfänger oft verwirrend ist: Der Job läuft möglicherweise genau nach Zeitplan, aber die Fehlermeldungen sind in dem Terminal nicht sichtbar, in dem Sie die Crontab erstellt haben. Automatisierte Prozesse im Hintergrund benötigen eine bewusst eingerichtete Protokollierung.

In diesem Lab lernen Sie, wie Sie diese „stille“ Ausgabe erfassen, um Fehler zu untersuchen. Sie werden:

1. Einen Fehler simulieren: Einen Cron-Job erstellen, der garantiert einen Fehler erzeugt.
2. Die Standardfehlerausgabe umleiten: Den Operator 2> verwenden, um Fehlermeldungen zu erfassen.
3. Protokolle analysieren: Die erfasste Ausgabe lesen, um die Ursache des Fehlers zu überprüfen.

Einen fehlschlagenden Cron-Job erstellen

Erstellen Sie zunächst absichtlich eine fehlerhafte Aufgabe, um einen Fehler zu simulieren. Weisen Sie Cron an, ein Verzeichnis aufzulisten, das nicht existiert.

Öffnen Sie die Crontab Ihres Benutzers:

crontab -e

Gehen Sie im Editor ans Ende der Datei, also unter alle Kommentare, und fügen Sie diese Zeile ein:

* * * * * ls /this/directory/does/not/exist

Konfigurationsdetails:

• Zeitplan: * * * * * (Wird jede Minute ausgeführt).
• Befehl: ls ... (Versucht, einen nicht vorhandenen Pfad aufzulisten).

Speichern Sie die Datei und schließen Sie den Editor.

Warten Sie nun mindestens eine Minute.

Beobachten Sie Ihr Terminal. ...

Auf Ihrem Bildschirm passiert nichts. Dies ist ein stiller Fehler. Der Befehl wurde ausgeführt, ist fehlgeschlagen und hat eine Fehlermeldung erzeugt. Diese Meldung hatte jedoch kein Ziel und wurde deshalb verworfen.

Dass keine Ausgabe erscheint, bedeutet nicht, dass „nichts passiert ist“. Es bedeutet, dass der Prozess kein interaktives Terminal zugeordnet hatte. Dieser Unterschied ist entscheidend für die Fehlersuche bei geplanten Jobs.

Die Standardfehlerausgabe (stderr) umleiten

Damit die Fehlermeldung sichtbar wird, müssen Sie den Stream Standard Error (stderr) in eine Datei umleiten.

Unter Linux sind Dateideskriptoren nummeriert:

• 0: Standardeingabe (stdin)
• 1: Standardausgabe (stdout)
• 2: Standardfehlerausgabe (stderr)

Mit 2> leiten Sie Kanal 2, also Fehlermeldungen, in eine Datei um.

Dabei wird dasselbe Shell-Umleitungsmodell verwendet, das Sie zuvor kennengelernt haben. Cron startet einen Befehl, die Shell verarbeitet dessen Dateideskriptoren, und die Umleitung bestimmt, wohin die einzelnen Streams gelangen.

Öffnen Sie Ihre Crontab erneut:

crontab -e

Ändern Sie die Zeile so, dass sie exakt wie folgt aussieht:

* * * * * ls /this/directory/does/not/exist 2> /home/labex/project/cron_error.log

Wichtige Änderungen:

• 2>: Leitet den Fehler-Stream um.
• /home/labex/project/cron_error.log: Der absolute Pfad zur Protokolldatei.
  • Wichtig: Verwenden Sie in Cron-Jobs immer absolute Pfade, zum Beispiel /home/labex/.... Cron wird in einer minimalen Umgebung ausgeführt und weiß nicht, worauf sich ~ oder relative Pfade beziehen.

Diese minimale Umgebung ist ein weiteres wichtiges Cron-Konzept. Geplante Jobs haben normalerweise weniger Umgebungsvariablen, einen eingeschränkten PATH und keinen Kontext einer interaktiven Shell. Befehle, die manuell funktionieren, können daher unter Cron fehlschlagen, wenn sie von solchen impliziten Annahmen abhängen.

Speichern Sie die Datei und schließen Sie den Editor.

Die Protokolldatei analysieren

Warten Sie noch eine Minute, damit der Job erneut ausgeführt wird.

Prüfen Sie nun, ob die Protokolldatei den Fehler erfasst hat:

cat ~/project/cron_error.log

Die Fehlermeldung sollte nun eindeutig in der Datei aufgezeichnet sein: ls: cannot access '/this/directory/does/not/exist': No such file or directory

Aufräumen: Es ist keine gute Praxis, fehlschlagende Jobs im Hintergrund weiterlaufen zu lassen.

1. Öffnen Sie crontab -e.
2. Löschen Sie die Zeile, die zu diesem Lab gehört.
3. Speichern Sie die Datei und schließen Sie den Editor.

Sie haben nun erfolgreich einen Hintergrundprozess untersucht, indem Sie dessen Fehlerausgabe erfasst haben.

Im praktischen Betrieb stellen sich viele Cron-Probleme als Umgebungsprobleme, fehlende Pfade oder fehlende Berechtigungen heraus und nicht als Fehler in der Befehlssyntax. Die erfasste Ausgabe zeigt oft am schnellsten, welcher Problemkategorie der tatsächliche Fehler zuzuordnen ist.

Zusammenfassung

In diesem Lab haben Sie gelernt, wie Sie die Ausgabe von Cron-Jobs im Hintergrund verarbeiten:

1. Die Herausforderung: Cron-Jobs schlagen unbemerkt fehl, wenn ihre Ausgabe nicht verarbeitet wird.
2. Die Lösung: Die Standardfehlerausgabe mit 2> umleiten, um Fehlermeldungen zu erfassen.
3. Bewährte Vorgehensweise: Protokollieren Sie die Ausgabe automatisierter Aufgaben immer, damit Sie Fehler bei Bedarf untersuchen können.

Diese Technik (2> error.log) ist unverzichtbar, um zuverlässige Automatisierungsskripte in jeder Linux-Umgebung zu betreiben.