Cronjob einrichten unter Linux (Crontab)

Ob regelmäßige Backups, Datenbank-Bereinigungen oder der Versand automatischer Reports – ein Cronjob erledigt das zuverlässig im Hintergrund, ohne dass jemand manuell eingreifen muss.

Das zentrale Werkzeug dafür ist die Crontab (kurz für „Cron Table"): eine Konfigurationsdatei, in der festgelegt wird, welcher Befehl wann und in welchem Intervall ausgeführt werden soll. Die Syntax wirkt auf den ersten Blick kryptisch – ist aber schnell durchschaut, wenn man das Schema einmal verstanden hat.

Jeder Benutzer auf dem System hat eine eigene Crontab. Bearbeitet wird sie mit:

Beim ersten Aufruf fragt das System nach dem bevorzugten Editor (z. B. nano oder vi). Die Datei wird nach dem Speichern automatisch aktiviert – ein Neustart von Cron ist nicht nötig.

Für systemweite Cronjobs, die als root laufen sollen:

Jede Zeile in der Crontab folgt dem gleichen Schema – fünf Zeitfelder, gefolgt vom auszuführenden Befehl:

Ein Stern (*) bedeutet „jeder mögliche Wert". Wer alle fünf Felder auf Stern lässt, führt den Befehl jede Minute aus.

Jeden Tag um 3:00 Uhr nachts (typisch für Backups):

Alle 15 Minuten:

Jeden Montag um 8:00 Uhr:

Am 1. jedes Monats um Mitternacht:

Alle 6 Stunden:

Werktags um 9:00 und 17:00 Uhr:

Vorhandene Cronjobs anzeigen

Zeigt alle Cronjobs des aktuellen Benutzers. Für die Cronjobs eines anderen Benutzers (als root):

Neben den benutzerspezifischen Crontabs gibt es systemweite Verzeichnisse, in denen Skripte nach Intervall einsortiert werden können:

Skripte, die in einem dieser Verzeichnisse liegen, brauchen keine Crontab-Zeile – sie werden automatisch von anacronoder run-parts aufgerufen. Wichtig: Die Skripte müssen ausführbar sein (chmod +x) und dürfen keinen Punkt im Dateinamen haben (also backup statt backup.sh).

Zusätzlich existiert die Datei /etc/crontab, die wie eine normale Crontab funktioniert, aber ein zusätzliches Feld für den Benutzernamen enthält:

Standardmäßig versucht Cron, die Ausgabe eines Jobs per E-Mail an den jeweiligen Benutzer zu schicken. Auf Servern ohne konfigurierten Mailversand führt das zu Problemen. Besser ist es, die Ausgabe gezielt in eine Logdatei umzuleiten:

>> /var/log/backup.log hängt die Standardausgabe an die Logdatei an.2>&1 leitet auch Fehlermeldungen dorthin um. Wer die Ausgabe komplett unterdrücken will:

Cronjobs laufen in einer minimalen Shell-Umgebung – das heißt, viele Umgebungsvariablen, die in einer normalen SSH-Sitzung verfügbar sind, fehlen. Zwei Dinge helfen:

Die PATH-Variable am Anfang der Crontab setzen:

Oder im Befehl immer den vollständigen Pfad angeben – sowohl zum Skript als auch zu allen Programmen, die das Skript aufruft.

Cronjob läuft nicht? In den meisten Fällen liegt es an fehlenden Berechtigungen (Skript nicht ausführbar) oder an einer falschen PATH-Variable. Cron loggt seine Aktivitäten in /var/log/syslog (Debian/Ubuntu) bzw. /var/log/cron (RHEL-basiert):

Prozent-Zeichen in Befehlen? Cron interpretiert % als Zeilenumbruch. In Befehlen mit Datumsformatierung wie date +%Y-%m-%d muss das Prozentzeichen mit einem Backslash escaped werden: date +%Y-%m-%d.

Crontab versehentlich gelöscht? crontab -r löscht die gesamte Crontab ohne Rückfrage. Wer sich vertippt und statt crontab -e ein crontab -r eingibt, hat ein Problem. Es lohnt sich, eine Sicherungskopie anzulegen:

Für die häufigsten Intervalle bietet Cron Abkürzungen, die statt der fünf Zeitfelder verwendet werden können: