cron – Aufgaben, die von selbst laufen (und warum sie es oft nicht tun)
Nächtliches Backup, wöchentlicher Bericht, stündliche Bereinigung: Fünf Zahlen und ein Befehl reichen. Der häufigste Fehler ist dabei nicht die Zeitangabe, sondern eine Umgebung, die ganz anders aussieht als dein Terminal.
Jede wiederkehrende Aufgabe, die du von Hand machst, vergisst du irgendwann. cron ist auf jedem Linux-Server der einfachste Weg, das abzustellen.
crontab -e # Aufgaben des aktuellen Nutzers bearbeiten
crontab -l # anzeigenDie fünf Zahlen
┌── Minute (0–59)
│ ┌── Stunde (0–23)
│ │ ┌── Tag im Monat (1–31)
│ │ │ ┌── Monat (1–12)
│ │ │ │ ┌── Wochentag (0–7, 0 und 7 = Sonntag)
│ │ │ │ │
* * * * * befehlBeispiele, die ich tatsächlich benutze:
0 3 * * * /usr/local/bin/backup.sh # täglich um 3:00
*/15 * * * * /usr/local/bin/sync.sh # alle 15 Minuten
0 8 * * 1 /usr/local/bin/wochenbericht.sh # montags um 8:00
0 0 1 * * /usr/local/bin/monatsabschluss.sh # am 1. jedes MonatsStatt der fünf Zahlen gehen auch Kurzformen: @daily, @hourly, @weekly, @reboot.
Die drei Gründe, warum es nicht läuft
Die Zeitangabe ist selten das Problem. Diese drei sind es:
1. PATH ist fast leer. Im Terminal findet die Shell php, rsync oder node, weil dein Profil den Pfad gesetzt hat. cron lädt dein Profil nicht. Deshalb: immer vollständige Pfade schreiben.
# ⚠️ findet php womöglich nicht
0 3 * * * php /var/www/wartung.php
# ✅ eindeutig
0 3 * * * /usr/bin/php /var/www/wartung.phpWelcher Pfad das ist, sagt dir which php.
2. Das Arbeitsverzeichnis ist das Heimatverzeichnis. Relative Pfade im Skript zeigen dann ins Leere. Entweder im Skript cd an den Anfang setzen oder im Eintrag:
0 3 * * * cd /var/www && /usr/bin/php wartung.php3. Das Prozentzeichen hat eine Sonderbedeutung. In einer crontab-Zeile ist % ein Zeilenumbruch für die Eingabe des Befehls. Ein date +%Y-%m-%d bricht deshalb ab — du musst es maskieren: date +\%Y-\%m-\%d. Das kostet erfahrungsgemäß eine halbe Stunde Suche, wenn man es nicht weiß.
Ausgabe nicht verlieren
Standardmäßig schickt cron alles, was das Skript ausgibt, per Mail an den Nutzer. Auf einem Server, der kein Mailsystem hat, verschwindet es damit spurlos. Deshalb schreibe ich in eine Datei:
0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1Das 2>&1 ist der entscheidende Teil: Es leitet auch die Fehlerausgabe in dieselbe Datei. Ohne das steht im Log nur, was gut lief.
Testen, ohne einen Tag zu warten
Der ehrlichste Test ist, die Umgebung von cron nachzustellen:
env -i /bin/sh -c '/usr/local/bin/backup.sh'env -i startet ohne jede Umgebungsvariable. Läuft dein Skript so durch, läuft es auch unter cron. Läuft es nicht, hast du genau das Problem gefunden, das dich sonst erst morgen früh erreicht hätte.
Wann nicht cron?
Wenn die Aufgabe länger läuft als das Intervall, starten mehrere Durchläufe parallel. Dagegen hilft eine Sperrdatei über flock:
*/15 * * * * /usr/bin/flock -n /tmp/sync.lock /usr/local/bin/sync.shDas -n heißt: Läuft schon einer, überspringe diesen Durchlauf, statt zu warten.
Du hast auf deinem Server wiederkehrende Aufgaben, die du noch von Hand machst? Das ist meistens eine Stunde Arbeit und danach für immer erledigt. Schreib mir.
Quellen
Du brauchst mehr als ein Snippet?
Ich entwickle Android-Apps in Kotlin und moderne Websites für Selbstständige und kleine Unternehmen — von der ersten Idee bis zum Release.
Projekt anfragen →Verwandte Snippets
timeout: Befehle, die sich festfahren, nach N Sekunden abbrechen
Ein Skript, das jede Nacht läuft, hängt irgendwann an einem Server, der nicht mehr antwortet – und dann läuft es eben nicht mehr zu Ende. timeout ist ein einziges Wort vor dem Befehl und macht aus dem Hänger einen sauberen Fehler.
Warum deine Zählvariable nach der Schleife wieder 0 ist – Prozess-Substitution in Bash
Ein Klassiker, der jeden einmal erwischt: Du zählst in einer while-Schleife hoch, und hinterher steht die Variable trotzdem auf 0. Schuld ist eine Subshell hinter der Pipe. Mit Prozess-Substitution behältst du das Ergebnis – und kannst nebenbei zwei Befehle direkt vergleichen.
Zwei Listen vergleichen mit comm – wer fehlt, wer ist neu, wer ist in beiden
Welche Dateien fehlen im Backup? Welche Kunden aus der alten Liste stehen nicht in der neuen? Für genau diese Fragen gibt es seit Unix-Urzeiten ein Werkzeug, das kaum jemand kennt – comm vergleicht zwei sortierte Listen und sagt dir in einer Zeile, was nur links, nur rechts oder in beiden steht.