Cronjobs einrichten: sicher planen und betreiben

Cronjobs richten Sie ein, indem Sie zuerst Benutzer, Befehl und erwartetes Ergebnis festlegen, danach die fünf Zeitfelder in die Crontab schreiben und den Lauf unter derselben Umgebung testen. Absolute Pfade, eine definierte Zeitzone, eine Überlappungssperre, verwertbare Protokolle und ein gesicherter Rückweg gehören zum Auftrag, nicht zur Kür.

Erst den Auftrag, dann den Zeitplan festlegen

Eine Zeitzeile beantwortet nur, wann ein Prozess gestartet werden soll. Sie sagt nicht, ob Eingaben vorhanden sind, das Ziel beschreibbar ist oder ein früherer Lauf noch arbeitet. Definieren Sie deshalb zuerst den Betriebsvertrag: Benutzer, Arbeitsverzeichnis, Eingaben, Ausgabe, zulässige Laufzeit und sichtbares Erfolgskriterium.

Der geplante Befehl sollte ohne interaktive Rückfrage auskommen. Er darf nicht auf ein angemeldetes Terminal, einen grafischen Schlüsselbund oder Variablen aus Ihrem persönlichen Shell-Profil angewiesen sein. Ein Skript, das nur in Ihrer Sitzung funktioniert, ist noch kein Cronjob.

Prüfen Sie vor dem ersten Eintrag:

• Identität: Unter welchem Konto soll die Aufgabe laufen?
• Wirkung: Darf ein zweiter Lauf parallel beginnen?
• Erfolg: Welches Ergebnis belegt einen vollständigen Lauf?
• Fehler: Wohin gehen Standardausgabe, Fehlerausgabe und Rückgabestatus?
• Rückweg: Wie entfernen Sie den Eintrag und stellen den vorherigen Zustand wieder her?

Benutzer-Crontab und System-Crontab nicht verwechseln

Mit crontab -e bearbeiten Sie gewöhnlich die Tabelle des aktuellen Benutzers. Der Cron-Daemon führt deren Befehle unter genau diesem Konto aus. In einer Benutzer-Crontab steht kein Benutzername zwischen Zeitplan und Befehl. Wer dort einen Namen ergänzt, verschiebt den eigentlichen Befehl und erzeugt einen schwer lesbaren Fehler.

Systemweite Tabellen wie die zentrale System-Crontab und Dateien im dafür vorgesehenen Systemverzeichnis enthalten dagegen ein zusätzliches Benutzerfeld. Diese Dateien gehören in die Verwaltung des Betriebssystems. Für eine einzelne Anwendung ist die Benutzer-Crontab meist der kleinere und besser begrenzte Eingriff.

Verwenden Sie kein privilegiertes Konto, nur weil ein Pfad sonst nicht zugänglich ist. Reparieren Sie Besitz, Gruppenmodell oder Zielverzeichnis, statt eine Rechtefrage durch größere Befugnisse zu verdecken.

Die fünf Zeitfelder richtig lesen

Die klassische Reihenfolge lautet Minute, Stunde, Tag des Monats, Monat und Wochentag. Danach folgt in der Benutzer-Crontab der Befehl. Ein Stern bedeutet jeder zulässige Wert. Listen trennen Werte mit Kommas, Bereiche verwenden einen Bindestrich, Schritte einen Schrägstrich.

Ein täglicher Lauf um 02:15 Uhr sieht in einer Benutzer-Crontab so aus:

15 2 * * * /home/app/bin/daily-report

Ein Lauf an Werktagen um 06:30 Uhr verwendet einen Bereich im Wochentagsfeld:

30 6 * * 1-5 /home/app/bin/import-data

Die beiden Tagesfelder sind eine Falle. Wenn Tag des Monats und Wochentag beide eingeschränkt sind, führen verbreitete Vixie- und Cronie-Implementierungen den Auftrag aus, sobald eines der Felder passt. Wer beide Bedingungen gleichzeitig erwartet, plant ungewollte Zusatzläufe.

Schrittangaben beginnen innerhalb ihres jeweiligen Feldes neu. Ein Minutenmuster beschreibt daher Positionen innerhalb einer Stunde, nicht automatisch einen lückenlosen Abstand über Stunden- oder Tagesgrenzen. Prüfen Sie den tatsächlich folgenden Ausführungszeitpunkt mit den Werkzeugen Ihrer installierten Cron-Variante.

Umgebung und Arbeitsverzeichnis ausdrücklich setzen

Cron startet keine normale Anmeldeshell. Klassische Implementierungen setzen unter anderem SHELL, HOME und LOGNAME, doch die übrige Umgebung kann deutlich von Ihrer Sitzung abweichen. Verlassen Sie sich nicht auf Ihren interaktiven PATH. Schreiben Sie ausführbare Programme und Skripte mit absoluten Pfaden aus.

Eine überschaubare Benutzer-Crontab kann die benötigte Umgebung am Anfang sichtbar festlegen:

SHELL=/bin/sh
PATH=/usr/local/bin:/usr/bin:/bin
MAILTO=ops@example.invalid

15 2 * * * /home/app/bin/daily-report

Der Platzhalter example.invalid ist absichtlich nicht zustellbar. Ersetzen Sie ihn durch einen überwachten Empfänger oder wählen Sie eine andere belastbare Alarmierung. Prüfen Sie außerdem, ob auf dem System überhaupt ein Mail-Transport eingerichtet ist. Eine MAILTO-Zeile allein beweist keine Zustellung.

Setzen Sie das Arbeitsverzeichnis im Skript oder in einem kontrollierten Wrapper. Relative Pfade hängen sonst davon ab, wo der Daemon den Prozess startet. Zugangsdaten gehören nicht in die Auftragszeile, weil Prozesslisten, Sicherungen oder Fehlermeldungen sie sichtbar machen können. Nutzen Sie eine geschützte Konfigurationsdatei, die nur das ausführende Konto lesen darf.

Zeitzone und Sommerzeit als Fachentscheidung behandeln

Ein Zeitplan ist ohne Zeitzone unvollständig. Soll die Aufgabe nach lokaler Geschäftszeit laufen oder nach einer stabilen technischen Referenz wie UTC? Schreiben Sie diese Entscheidung in die Betriebsdokumentation und prüfen Sie Systemzeit, Zeitzone sowie Uhrensynchronisation auf dem Zielserver.

Bei der Umstellung zwischen Sommer- und Winterzeit gibt es lokale Uhrzeiten, die ausfallen oder doppelt vorkommen. Cron-Implementierungen behandeln solche Sprünge nicht einheitlich. Cronie dokumentiert sowohl einfache Trefferfolgen als auch besondere Daemon-Behandlung; andere Varianten können abweichen. Verlassen Sie sich deshalb nicht auf ein Verhalten, das nur auf einem anderen System beobachtet wurde.

Wenn ein Lauf exakt an eine lokale Abrechnungs- oder Geschäftsgrenze gebunden ist, testen Sie die installierte Variante gezielt. Ist ein gleichmäßiger technischer Takt wichtiger, kann UTC die robustere Grundlage sein. Die Entscheidung gehört zur Fachlogik; ein nachträglich gesetztes Zeitzonenpräfix heilt keine unklare Anforderung.

Überlappung mit einer Sperre begrenzen

Cron startet nach Zeitplan, auch wenn die vorherige Aufgabe länger dauert als erwartet. Zwei Importe können dieselben Dateien schreiben, zwei Sicherungen denselben Zielbestand verändern oder zwei Abrechnungen denselben Datensatz verarbeiten. Die Laufzeit ist deshalb ein Planungswert, kein Detail nach dem ersten Zwischenfall.

Unter Linux kann util-linux flock einen Befehl mit einer exklusiven Dateisperre umschließen. Die nicht wartende Variante beendet den neuen Versuch, wenn die Sperre bereits gehalten wird:

*/10 * * * * /usr/bin/flock -n /home/app/run/import.lock /home/app/bin/import-data

Die Sperrdatei muss in einem Verzeichnis liegen, das nur der vorgesehene Benutzer passend beschreiben kann. Eine weltweit beschreibbare Ablage öffnet unnötige Manipulationsflächen. Prüfen Sie den Rückgabestatus bei einem Sperrkonflikt und entscheiden Sie bewusst, ob dieser Zustand protokolliert, alarmiert oder lediglich gezählt wird.

Eine Sperre verhindert Parallelität, aber keine doppelte fachliche Wirkung nach einem Neustart. Idempotenz bleibt Aufgabe des Programms. Es sollte einen bereits verarbeiteten Datensatz erkennen, Zwischenstände atomar schreiben und einen wiederholten Lauf ohne beschädigten Zielzustand vertragen.

Ein Cronjob ist erst vollständig, wenn neben dem Startzeitpunkt auch Parallelität, Ausgabe und Kontrolle festgelegt sind.

Ausgabe, Fehler und Mail nicht verschwinden lassen

Klassischer Cron kann Standardausgabe und Fehlerausgabe per Mail an den Eigentümer oder den in MAILTO genannten Empfänger senden. Das funktioniert nur mit einer passenden lokalen Mail-Konfiguration. Leere Ausgabe ist außerdem kein Erfolgsbeweis: Ein Programm kann ohne Text fehlschlagen oder mit viel Text erfolgreich sein.

Für einen einfachen Auftrag können Sie beide Ausgabekanäle an eine geschützte Logdatei anhängen:

15 2 * * * /home/app/bin/daily-report >> /home/app/log/daily-report.log 2>&1

Planen Sie Rotation, Speichergrenze und Zugriffsrechte der Datei. Ein endlos wachsendes Protokoll wird selbst zum Ausfallpfad. Schreiben Sie Beginn, Ende und einen eindeutigen Auftragsbezug in die Anwendungsausgabe. Alarmieren Sie auf den Rückgabestatus oder ein fehlendes Erfolgssignal, nicht bloß auf vorhandenen Text.

Leiten Sie Ausgabe nicht pauschal in das Nullgerät um, bevor der Auftrag beobachtet wird. Damit entfernen Sie oft den einzigen Hinweis auf falsche Pfade, fehlende Rechte oder eine nicht erreichbare Gegenstelle. Erst wenn eine andere Überwachung nachweislich greift, darf stille Ausgabe eine bewusste Entscheidung sein.

Rechte nach dem kleinsten notwendigen Umfang vergeben

Der Cronjob erbt die Rechte seines ausführenden Kontos. Dieses Konto muss das Programm ausführen, Eingaben lesen und ausschließlich die vorgesehenen Ziele verändern dürfen. Es braucht keine weitergehenden Befugnisse. Testen Sie den Befehl als genau dieser Benutzer, nicht als Administrator mit einer bequemeren Umgebung.

Prüfen Sie auch alle Elternverzeichnisse des Pfads. Ein lesbares Skript hilft nicht, wenn dem Konto das Durchquerungsrecht an einem Verzeichnis fehlt. Für Sperren, Protokolle und temporäre Dateien brauchen Sie getrennte Schreibziele mit nachvollziehbarem Eigentümer- und Gruppenmodell.

Test, Einbau und Rückweg trennen

Sichern Sie die bestehende Benutzer-Crontab, bevor Sie sie ändern. Der folgende Befehl schreibt eine lesbare Kopie in Ihr Heimatverzeichnis; kontrollieren Sie danach Inhalt und Dateirechte:

crontab -l > "$HOME/crontab.before"

Führen Sie das Zielprogramm anschließend manuell als geplanter Benutzer mit einer auf Cron reduzierten Umgebung aus. Verwenden Sie Testdaten oder einen ungefährlichen Prüfmodus, falls die Aufgabe externe Nebenwirkungen hat. Der Test muss Rückgabestatus, Ausgabe, Sperrkonflikt und einen wiederholten Lauf abdecken.

Installieren Sie zunächst einen einzelnen, gut beobachtbaren Termin. Prüfen Sie danach die geladene Tabelle mit crontab -l, warten Sie auf den Lauf und vergleichen Sie Ergebnis sowie Protokoll. Fragen Sie nach dem Ausfallpfad: Wenn niemand den ersten Fehllauf bemerkt, ist die Automatisierung nicht fertig.

Für den Rückweg entfernen Sie nur die neue Zeile oder installieren die geprüfte Sicherung erneut:

crontab "$HOME/crontab.before"

Verwenden Sie nicht vorschnell crontab -r. Dieser Befehl entfernt die gesamte Benutzertabelle und macht aus einem lokalen Fehler einen vollständigen Ausfall aller dort geplanten Aufgaben.

Wann ein systemd-Timer besser passt

Cron bleibt passend für kurze, unabhängige Zeitaufträge mit einfacher Umgebung. Ein systemd-Timer trennt dagegen Zeitdefinition und Dienst, integriert Status und Journal und kann Kalender- sowie monotone Auslöser modellieren. Je nach Konfiguration kann er verpasste Termine nachholen und Ressourcen oder Abhängigkeiten am Dienst ausdrücken.

Ein systemd-Timer startet keine zweite Instanz, wenn die zu aktivierende Diensteeinheit noch aktiv ist. Das ist eine hilfreiche Grenze, ersetzt aber keine Idempotenz und keine fachliche Prüfung des Ergebnisses. Auch Genauigkeit und zufällige Verzögerung sind eigene Einstellungen, nicht stillschweigende Garantien.

Wechseln Sie nicht wegen einer modischen Vorliebe. Wählen Sie das Werkzeug, dessen Ausfallpfad Sie prüfen können. Betrieb schlägt Prospekt, auch bei einem Zeitplaner.

Fazit

Ein guter Cronjob besteht nicht nur aus fünf Zeitfeldern. Er hat einen begrenzten Benutzer, eine reproduzierbare Umgebung, eine klare Zeitzone, eine Regel gegen Überlappung und einen sichtbaren Erfolgsnachweis. Testen Sie den kleinsten Lauf zuerst und sichern Sie den Rückweg, bevor der Zeitplan unbeaufsichtigt arbeitet.