Linux Cron Job: geplante Aufgaben mit Crontab

Ein Linux Cron Job ist eine geplante Aufgabe, die im Hintergrund einen Befehl oder ein Skript nach einem von dir festgelegten Zeitplan ausführt. Wenn du möchtest, dass wiederkehrende Arbeiten — Backups, Logs aufräumen, eine API abfragen oder den Scheduler von Laravel anstoßen — vom System statt von Hand ausgelöst werden, ist Cron genau das richtige Werkzeug. In dieser Anleitung gehe ich die Crontab-Syntax, praxisnahe Beispiele, das Logging und die häufigsten Stolperfallen durch.

cron, crontab und der Cron-Daemon

Drei Begriffe auseinanderzuhalten macht alles klarer:

• cron: der ständig laufende Hintergrunddienst, der die Uhr überwacht und Aufgaben auslöst (der Daemon, auf den meisten Distributionen cron oder crond genannt).
• crontab: die „Cron-Tabelle", die Konfigurationsdatei, in der die Aufgaben stehen. Jeder Benutzer hat seine eigene Crontab.
• Cron Job: eine einzelne Zeile in dieser Tabelle — ein Zeitplan plus ein auszuführender Befehl.

Um die eigene Crontab zu bearbeiten:

crontab -e      # bearbeiten
crontab -l      # aktuelle Aufgaben auflisten
crontab -r      # alle Aufgaben löschen (Vorsicht!)

Crontab-Syntax: die fünf Felder

Jede Zeile besteht aus fünf Zeitfeldern, gefolgt vom Befehl:

# ┌───────── Minute        (0-59)
# │ ┌─────── Stunde        (0-23)
# │ │ ┌───── Tag des Monats(1-31)
# │ │ │ ┌─── Monat         (1-12)
# │ │ │ │ ┌─ Wochentag     (0-7, 0 und 7 = Sonntag)
# │ │ │ │ │
# * * * * *  auszufuehrender-befehl

In jedem Feld funktionieren Sonderzeichen:

• * — jeder Wert („jede Minute", „jede Stunde").
• , — eine Liste: 0,15,30,45.
• - — ein Bereich: 1-5 (Montag–Freitag).
• / — ein Schritt: */10 (alle 10 Einheiten).

Nützliche Cron-Beispiele

Die Syntax wirkt abstrakt; konkrete Beispiele schaffen Klarheit:

# Backup-Skript täglich um 02:30 Uhr
30 2 * * * /home/aslain/scripts/backup.sh

# Health-Check alle 5 Minuten
*/5 * * * * /usr/bin/curl -fsS https://aslain.dev/health

# Bericht um 09:00 Uhr an Werktagen
0 9 * * 1-5 /home/aslain/scripts/report.sh

# Log-Rotation um Mitternacht am 1. jedes Monats
0 0 1 * * /home/aslain/scripts/rotate-logs.sh

# Laravel-Scheduler alle 15 Minuten
*/15 * * * * cd /var/www/site && php artisan schedule:run

Du musst dir die Syntax nicht merken: Werkzeuge wie crontab.guru übersetzen einen Ausdruck in verständliche Sprache. Die Logik zu verstehen spart dir beim Debuggen dennoch Zeit.

Umgebungsvariablen und absolute Pfade

Das Tückischste an Cron ist, dass Jobs in einer sehr kargen Umgebung laufen. Der PATH, Aliase und Profil-Einstellungen aus deinem Terminal existieren in Cron nicht. Deshalb ist „in meiner Shell lief es, aber in Cron nicht" eine so häufige Klage.

• Schreibe Befehle und Dateien mit absoluten Pfaden: /usr/bin/php statt php, vollständige Pfade statt ./script.sh.
• Wechsle bei Bedarf mit cd ins richtige Verzeichnis oder verankere die Pfade fest.
• Deklariere die benötigten Variablen am Anfang der Crontab:

PATH=/usr/local/bin:/usr/bin:/bin
SHELL=/bin/bash
MAILTO=hello@aslain.dev

30 2 * * * /home/aslain/scripts/backup.sh

Um den richtigen Pfad zu finden, führe in deinem Terminal which php oder command -v node aus und verwende den ausgegebenen vollständigen Pfad.

Ausgabe protokollieren und Fehler abfangen

Standardmäßig versucht Cron, die Ausgabe eines Jobs per E-Mail an den Benutzer zu senden. Ist Mail nicht eingerichtet, verschwindet die Ausgabe und du siehst nicht, was schiefgelaufen ist. Die Lösung: leite die Ausgabe in eine Datei um.

# stdout und stderr in eine Logdatei schreiben
30 2 * * * /home/aslain/scripts/backup.sh >> /var/log/backup.log 2>&1

Hier schickt 2>&1 den Fehlerstrom (stderr) in dieselbe Datei wie die Standardausgabe (stdout), und >> hängt an, statt zu überschreiben. Für einen stillen Job, dessen Ausgabe dich nicht interessiert, nutzt du > /dev/null 2>&1 — aber erst, wenn das Debuggen abgeschlossen ist.

Du kannst auch in den Systemlogs prüfen, ob Jobs tatsächlich ausgelöst wurden:

grep CRON /var/log/syslog        # Debian/Ubuntu
journalctl -u cron --since today # systemd-basierte Systeme

Häufige Fehler

• Das Prozentzeichen. In der Crontab hat % eine Sonderbedeutung (Zeilenumbruch) und teilt den Befehl. Maskiere jedes % in Datumsformaten als \%.
• Überlappende Läufe. Ein Job, der länger dauert als sein Intervall, kann sich mit dem nächsten überschneiden. Sperre ihn mit flock: flock -n /tmp/job.lock /home/aslain/scripts/job.sh.
• Ausführungsrecht. Stelle sicher, dass das Skript ausführbar ist: chmod +x script.sh, mit einem Shebang (#!/bin/bash) in der ersten Zeile.
• Falscher Benutzer. Lege den Job in der Crontab des Benutzers an, der die passenden Rechte hat; für root-Jobs nutze sudo crontab -e.

Häufige Fragen

Wann sollte ich einen systemd-Timer statt Cron verwenden?

Auf modernen systemd-Distributionen sind Timer stärker bei Abhängigkeiten, verzögertem Start, dem Nachholen verpasster Läufe (Persistent=true) und detailliertem Logging. Für einfache periodische Aufgaben reicht Cron völlig aus und ist überall verfügbar; für komplexe, dienstartige Zeitpläne solltest du einen systemd-Timer in Betracht ziehen.

Kann ich etwas jede Sekunde ausführen?

Nein — die kleinste Einheit von Cron ist eine Minute. Für häufigere Ausführung nutze eine Schleife mit sleep in einem Skript oder wechsle zu einem systemd-Timer mit OnUnitActiveSec.

Was passiert mit Jobs, die verpasst werden, während der Server aus ist?

Klassisches Cron holt verpasste Läufe nicht nach; das Zeitfenster wird übersprungen, während die Maschine offline ist. Um verzögerte Jobs beim Booten auszuführen, nutze anacron oder die Option Persistent eines systemd-Timers.

Sind deine geplanten Aufgaben ein Durcheinander? Wenn du Backups, Deployments und Wartungsskripte auf deinem Server in zuverlässige Cron Jobs einbinden willst, melde dich bei mir — wir bauen gemeinsam ein sauberes, protokolliertes Setup auf.