Cron ist der klassische Job-Scheduler auf Unix/Linux-Systemen und ermöglicht es dir, Skripte und Befehle zeitgesteuert automatisch auszuführen. Die Konfiguration erfolgt über sogenannte Crontabs (cron tables) – Textdateien mit je einer Job-Definition pro Zeile. Diese Anleitung erklärt die komplette crontab-Syntax, die fünf Zeitfelder, Sonderstrings wie @reboot, den Unterschied zwischen Benutzer-Crontab und System-Crontab sowie die häufigsten Fehlerquellen rund um PATH und Logging. Sie richtet sich an Admins, die Cron-Jobs sicher einrichten und bei Problemen gezielt debuggen wollen.

Kurzfassung: Mit crontab -e öffnest du deine persönliche Crontab und trägst Jobs im Format Minute Stunde Tag Monat Wochentag Befehl ein. Nutze absolute Pfade oder setze PATH am Anfang der Crontab, um die häufigste Fehlerursache zu vermeiden. Logs findest du über grep CRON /var/log/syslog oder sudo journalctl -u cron.

Voraussetzungen

Linux-System mit installiertem Cron-Daemon (auf Debian/Ubuntu: cron, auf RHEL/CentOS: crond)
Terminalzugang mit deinem Benutzerkonto
Für System-Crontabs (/etc/crontab, /etc/cron.d/): Root-Rechte bzw. sudo
Grundlegende Kenntnisse der Bash-Kommandozeile

Schritt 1: Die crontab-Syntax verstehen – fünf Zeitfelder

Jede Zeile in einer Benutzer-Crontab besteht aus fünf Zeitfeldern und dem eigentlichen Befehl:

Minute  Stunde  Tag  Monat  Wochentag  Befehl
*       *       *    *      *          /pfad/zum/befehl

Die Felder im Überblick:

FeldWertebereichBedeutung

Minute

0–59

Minute der Stunde

Stunde

0–23

Stunde des Tages (24h)

Tag

1–31

Tag des Monats

Monat

1–12

Monat des Jahres

Wochentag

0–6 (oder 7)

Wochentag: 0 = Sonntag, 1 = Montag … 6 = Samstag; 7 = Sonntag (alternativ)

Ein Sternchen (*) steht für jeden möglichen Wert. Beispiele:

# Täglich um 02:30 Uhr
30 2 * * * /usr/local/bin/backup.sh

# Jeden Montag um 08:00 Uhr
0 8 * * 1 /home/user/wochenbericht.sh

# Jeden 1. des Monats um Mitternacht
0 0 1 * * /usr/local/bin/monatsauswertung.sh

Schritt 2: Schritt-, Listen- und Bereichswerte kombinieren

Die crontab-Syntax erlaubt drei Erweiterungen, die du einzeln oder kombiniert einsetzen kannst:

Schrittweite */5: alle 5 Einheiten (z. B. jede 5. Minute)
Bereich 1-5: von 1 bis 5 (einschließlich)
Liste 1,15,30: nur diese konkreten Werte
Kombiniert 0-30/5: alle 5 Minuten, aber nur in den ersten 30 Minuten der Stunde

# Alle 5 Minuten
*/5 * * * * /usr/bin/python3 /home/user/check.py

# Um :00, :15, :30 und :45 jeder Stunde
0,15,30,45 * * * * /usr/local/bin/ping_check.sh

# Mo bis Fr, jede 3 Stunden
0 */3 * * 1-5 /opt/cleanup.sh

# Alle 5 Min in den ersten 30 Min jeder Stunde
0-30/5 * * * * /usr/local/bin/kurzcheck.sh

Schritt 3: Benutzer-Crontab bearbeiten mit crontab -e, -l, -r

Deine persönliche Crontab liegt unter /var/spool/cron/crontabs/DEIN-BENUTZERNAME – diese Datei darfst du nicht direkt editieren. Nutze stattdessen die Befehle:

# Crontab im Standardeditor öffnen (erstellt sie, falls noch nicht vorhanden)
crontab -e

# Anderen Editor erzwingen (z. B. nano)
EDITOR=nano crontab -e

# Aktuelle Crontab anzeigen
crontab -l

# Crontab eines anderen Benutzers anzeigen (nur root)
crontab -u webadmin -l

# Crontab eines anderen Benutzers editieren (nur root)
crontab -u webadmin -e

# Crontab löschen – ACHTUNG: keine Rückfrage!
crontab -r

# Crontab löschen mit Bestätigungsabfrage
crontab -i -r

Wichtig: Nach dem Speichern übernimmt Cron die Änderungen automatisch, in der Regel innerhalb einer Minute. Du musst den Daemon nicht manuell neu starten.

Schritt 4: Sonderstrings @reboot, @daily, @hourly und Co.

Anstelle der fünf Zeitfelder kannst du praktische Sonderstrings verwenden. Sie machen die Crontab lesbarer, sind aber weniger flexibel als die volle Syntax:

SonderstringEntsprichtBedeutung

@reboot

–

Einmal nach jedem Systemstart

@hourly

0 * * * *

Jede Stunde zur vollen Stunde

@daily

0 0 * * *

Täglich um Mitternacht

@weekly

0 0 * * 0

Sonntags um Mitternacht

@monthly

0 0 1 * *

Am 1. jeden Monats um Mitternacht

@yearly / @annually

0 0 1 1 *

Am 1. Januar um Mitternacht

# VPN-Client nach jedem Reboot starten
@reboot /usr/local/bin/startvpn.sh

# Tägliche Bereinigung
@daily /usr/local/bin/cleanup.sh >> /var/log/cleanup.log 2>&1

Schritt 5: System-Crontab und /etc/cron.d verstehen

Neben der persönlichen Benutzer-Crontab gibt es systemweite Varianten. Der entscheidende Unterschied: Sie haben sechs Felder – das sechste ist der Benutzername, unter dem der Job ausgeführt wird.

# Format /etc/crontab und /etc/cron.d/:
Minute  Stunde  Tag  Monat  Wochentag  USERNAME  Befehl

Konkrete Beispiele:

# /etc/crontab: Backup täglich um 02:00 Uhr als root
0 2 * * * root /usr/local/bin/backup.sh

# /etc/cron.d/postgres-cleanup: Mo–Fr jede 3 Stunden als postgres, mit Log
0 */3 * * 1-5 postgres /opt/cleanup.sh >> /var/log/pg.log 2>&1

Empfehlung: /etc/crontab lieber nicht direkt anfassen. Lege für eigene System-Jobs separate Dateien in /etc/cron.d/ an – mit aussagekräftigen Namen wie /etc/cron.d/backup-nightly. So behältst du den Überblick und Pakete können ihre eigenen Job-Dateien getrennt verwalten.

# Alle System-Job-Dateien auflisten
ls -la /etc/cron.d/

# System-Crontab anzeigen
sudo cat /etc/crontab

Die Verzeichnisse /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly und /etc/cron.monthly nehmen ausführbare Skript-Dateien entgegen, die run-parts zu festen Zeiten (typisch 03:05 / 03:25 / 03:45 Uhr) aufruft. Wichtig dabei:

Skript-Datei muss ausführbar sein: chmod +x /etc/cron.daily/mein-skript
Dateiname nur mit ASCII-Buchstaben, Zahlen, Unterstrichen und Bindestrichen – keine Dateiendung (z. B. .sh). Dateien mit Endungen werden von run-parts ignoriert!
Manueller Test: sudo run-parts /etc/cron.daily

Schritt 6: PATH-Falle und Umgebungsvariablen richtig handhaben

Dies ist die häufigste Fehlerursache: Cron startet Jobs mit einer minimalen Umgebung, die sich stark von deiner interaktiven Shell unterscheidet:

PATH: nur /usr/bin:/bin – kein /usr/local/bin, kein /sbin, kein ~/.local/bin
SHELL: /bin/sh (POSIX-Shell, nicht Bash) – Bash-Syntax wie [[ oder Arrays funktioniert nicht
HOME und LOGNAME: aus /etc/passwd des Crontab-Besitzers
.bashrc, .bash_profile und andere Login-Skripte werden nicht geladen

Die zuverlässigste Lösung: absolute Pfade in allen Befehlen und Skripten verwenden. Alternativ setzt du Variablen am Anfang der Crontab:

# Umgebungsvariablen am Anfang der Crontab setzen
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
MAILTO=''

# Jobs folgen darunter
*/5 * * * * /usr/bin/python3 /home/user/job.py >> /var/log/job.log 2>&1
0 2 * * * /usr/local/bin/backup.sh

Schritt 7: Output, Logging und MAILTO konfigurieren

Standardmäßig versucht Cron, jede Ausgabe eines Jobs per E-Mail an den Crontab-Besitzer zu senden. Das führt in der Praxis oft zu einem vollen lokalen Mailspool. Du hast drei Alternativen:

Option A – Ausgabe in Logdatei umleiten (empfohlen):

*/5 * * * * /usr/local/bin/check.sh >> /var/log/check.log 2>&1

2>&1 leitet auch stderr in dieselbe Datei. Ohne diese Angabe landet stderr separat – und wird dann doch gemailt.

Option B – Alle Mails deaktivieren mit MAILTO='' :

MAILTO=''
*/5 * * * * /usr/local/bin/check.sh

Option C – Ausgabe an syslog per logger schicken:

*/5 * * * * /usr/local/bin/check.sh | /usr/bin/logger -t CRONJOB

Lokale Cron-E-Mails liest du so:

less /var/mail/$(whoami)

Cron-Logs auf verschiedenen Distributionen:

# Debian / Ubuntu – alle Cron-Einträge filtern
grep CRON /var/log/syslog

# RHEL / CentOS
grep CRON /var/log/cron

# Systemd-basierte Distros (moderne Debian/Ubuntu, RHEL 7+)
sudo journalctl -u cron

# Nur die letzten 24 Stunden, nur tatsächliche Ausführungen
sudo journalctl -u cron --since '24 hours ago' | grep CMD

Troubleshooting

Problem: Job läuft nie. Überprüfe mit crontab -l, ob der Eintrag wirklich gespeichert ist. Prüfe, ob der Cron-Daemon läuft (systemctl status cron bzw. crond). Kontrolliere die Systemzeit. Schau in journalctl -u cron, ob Cron den Job überhaupt plant.
Problem: Befehl funktioniert in der Shell, aber nicht im Cron-Job. PATH-Falle – nutze absolute Pfade. Teste mit: env -i PATH=/usr/bin:/bin /pfad/zum/skript.sh, um die Cron-Umgebung zu simulieren.
Problem: Bash-Syntax-Fehler im Cron-Job. Cron verwendet /bin/sh, nicht Bash. Setze SHELL=/bin/bash am Anfang der Crontab oder füge #!/bin/bash als Shebang in dein Skript ein.
Problem: Unerwartete E-Mails von Cron. Jede Ausgabe (auch stdout bei Erfolg) wird gemailt. Lösung: >> /var/log/job.log 2>&1 anhängen oder MAILTO='' setzen.
Problem: Skript in /etc/cron.daily wird nicht ausgeführt. Zwei häufige Ursachen: (1) Datei nicht ausführbar – chmod +x /etc/cron.daily/mein-skript. (2) Dateiname hat eine Endung wie .sh – run-parts ignoriert solche Dateien. Datei umbenennen.
Problem: /etc/cron.d-Job läuft nicht. Das sechste Feld (Benutzername) fehlt. Format prüfen: Minute Stunde Tag Monat Wochentag USERNAME Befehl.
Problem: Wochentag-Logik verhält sich unerwartet. Wenn sowohl Tag-des-Monats als auch Wochentag gesetzt sind (beide nicht *), verknüpft Cron beide mit ODER, nicht UND – der Job läuft, wenn einer der beiden Bedingungen erfüllt ist.

Häufige Fragen

Was ist der Unterschied zwischen /etc/crontab und /etc/cron.d/?

/etc/crontab ist eine einzelne Systemdatei, die direkt (ohne crontab-Kommando) editiert wird. /etc/cron.d/ ist ein Verzeichnis, in das Pakete und Admins separate Job-Dateien legen. Beide verwenden das Sechs-Felder-Format mit Benutzername. Best Practice: Finger weg von /etc/crontab, eigene Jobs in /etc/cron.d/ als separate Datei anlegen.

Kann ich mehrere Befehle in einen Cron-Job packen?

Ja, mit && (zweiter Befehl nur bei Erfolg des ersten) oder ; (zweiter Befehl immer). Besser ist es, ein Shell-Skript zu schreiben und dieses aus der Crontab aufzurufen – das erleichtert Fehlersuche und Wartung erheblich.

Wie teste ich einen Cron-Job, ohne zu warten?

Führe den Befehl manuell in einer minimalen Umgebung aus, die Cron simuliert:

env -i HOME=/home/DEIN-USER PATH=/usr/bin:/bin SHELL=/bin/sh /pfad/zum/skript.sh

Für Jobs in /etc/cron.daily kannst du direkt sudo run-parts /etc/cron.daily aufrufen.

Was bedeutet Wochentag 7 – ist das ein Fehler?

Nein. Sowohl 0 als auch 7 stehen für Sonntag. Das ist eine historische Eigenheit verschiedener cron-Implementierungen. Verwende konsistent 0 für Sonntag, um Verwirrung zu vermeiden.

Werden Cron-Jobs ausgeführt, wenn der Rechner ausgeschaltet war?

Nein. Cron führt Jobs nur aus, wenn das System zum geplanten Zeitpunkt läuft. Verpasste Jobs werden nicht nachgeholt. Wenn du das brauchst, schau dir anacron an, das speziell für Systeme gedacht ist, die nicht durchgehend laufen.

Wie beschränke ich, welche Benutzer Crontabs anlegen dürfen?

Über die Dateien /etc/cron.allow (Whitelist) und /etc/cron.deny (Blacklist). Wenn /etc/cron.allow existiert, dürfen nur die dort aufgeführten Benutzer crontab -e verwenden. Wenn nur /etc/cron.deny existiert, dürfen alle außer den dort genannten Benutzern.

Fazit

Cron ist ein zuverlässiges und flexibles Werkzeug – vorausgesetzt, du kennst seine Eigenheiten. Die häufigsten Stolpersteine sind der eingeschränkte PATH, die POSIX-Shell statt Bash und fehlgeleitete Ausgaben, die den Mailspool füllen. Mit absoluten Pfaden, explizitem SHELL=/bin/bash und konsequenter Log-Umleitung in Dateien entschärfst du die meisten Probleme von vornherein. Für komplexere Anforderungen – etwa zeitkritische Jobs auf Systemen, die nicht durchgehend laufen – lohnt sich ein Blick auf anacron oder systemd-Timer als moderne Alternative.

Weiterführende Anleitungen und Quellen

Systemd-Service erstellen und verwalten – die Grundlagen – systemd-Timer als moderne Alternative zu Cron
Linux-Benutzer, Gruppen und Rechte mit chmod, chown und sudo verwalten – Datei-Permissions für Cron-Skripte richtig setzen
SSH-Key-Authentifizierung einrichten – Linux und Windows – Cron-Jobs, die per SSH auf andere Server zugreifen
Alle Linux-Anleitungen bei Schönfelder EDV

Quellen: Linux man-pages: crontab(5) · Ubuntu Manpage: crontab(5) · Cronitor: Cron Environment Variables · nixCraft: Crontab Troubleshooting