Die Position im Cron-Ausdruck bestimmt die Bedeutung:

Wichtig: Die ODER-Regel

Wenn du sowohl DOM (Tag des Monats) als auch DOW (Wochentag) setzt (nicht *), wird die Bedingung ODER-verknüpft:

Für "Freitag der 13." (nur wenn beides zutrifft):

• Mit Cron direkt nicht möglich
• Lösung 1: Skript-seitige Prüfung: if [ $(date +%d) -eq 13 ] && [ $(date +%u) -eq 5 ]; then ...
• Lösung 2: systemd.timer mit OnCalendar=Fri *-*-13
• Lösung 3: Jeden Freitag laufen lassen und im Skript prüfen

Best Practice: Setze nur DOM oder DOW, nicht beide – es sei denn, du willst genau dieses ODER-Verhalten.

Cron-Probleme haben fast immer eine dieser Ursachen:

1. PATH-Problem (häufigste Ursache)

• Cron hat einen minimalen PATH
• Nur /usr/bin:/bin meist verfügbar
• Lösung: Absolute Pfade verwenden
• Falsch: python3 /opt/script.py
• Richtig: /usr/bin/python3 /opt/script.py

2. Umgebungsvariablen fehlen

• $HOME, $USER, $LANG sind oft nicht gesetzt
• Lösung: In der Crontab definieren
• PATH=/usr/local/bin:/usr/bin:/bin
• MAILTO=admin@example.com

3. Keine Ausführungsrechte

• Skript muss ausführbar sein: chmod +x script.sh
• Shebang prüfen: #!/bin/bash

4. Logs prüfen!

5. Ausgabe umleiten

6. Weitere häufige Ursachen

• Crontab nicht geladen: crontab -l prüfen
• Syntax-Fehler: crontab -e zeigt Fehler
• Zeitzone: Server läuft in UTC, nicht lokal
• Doppelter Eintrag: Läuft 2× (z.B. in /etc/cron.d und crontab)
• SELinux/AppArmor: Blockiert Ausführung

Es gibt mehrere Wege, Crontab-Einträge zu bearbeiten:

1. Benutzer-Crontab (pro User)

2. System-Crontab

• /etc/crontab – Hauptdatei (mit User-Feld!)
• /etc/cron.d/ – Zusätzliche Jobs
• /etc/cron.hourly/ – Stündliche Skripte
• /etc/cron.daily/ – Tägliche Skripte
• /etc/cron.weekly/ – Wöchentliche Skripte
• /etc/cron.monthly/ – Monatliche Skripte

Unterschied /etc/crontab vs. crontab -e:

3. Crontab-Syntax prüfen

Beispielhafte Crontab

Beide haben ihre Berechtigung – hier die Unterschiede:

Feature	Cron	systemd.timer
Verfügbarkeit	Alle Unix-Systeme	Nur systemd-Systeme
Syntax	Einfach (5 Felder)	Komplexer
Sekundengenau	❌ Nein	✅ Ja
Verpasste Jobs	❌ Weg	✅ Nachholen (Persistent)
Logging	E-Mail oder Syslog	Journal (systemctl)
Ressourcen-Limits	❌ Nein	✅ CPU, RAM, IO
Dependencies	❌ Nein	✅ Requires, After
Umgebung	Minimal	Konfigurierbar
Komplexität	Niedrig	Höher

Beispiel systemd.timer:

Wann Cron?

• Einfache, wiederkehrende Jobs
• Kompatibilität mit alten Systemen
• Wenn du auf allen Systemen gleich arbeiten willst
• Schnelle Einrichtung

Wann systemd.timer?

• Sekundengenauigkeit benötigt
• Verpasste Jobs nachholen (z.B. Server war aus)
• Ressourcen-Limits erforderlich
• Komplexe Abhängigkeiten
• Bessere Integration mit systemd

Empfehlung: Moderne Systeme (systemd) → systemd.timer. Alte Systeme oder Container → Cron.

@reboot ist ein spezieller Cron-Ausdruck, der einen Job beim Systemstart ausführt:

Syntax:

Andere Spezial-Ausdrücke:

Ausdruck	Entspricht	Bedeutung
@reboot	—	Beim Start
@yearly	0 0 1 1 *	Jährlich (1. Jan, 0:00)
@annually	0 0 1 1 *	Wie @yearly
@monthly	0 0 1 * *	1. jeden Monats, 0:00
@weekly	0 0 * * 0	Sonntags, 0:00
@daily	0 0 * * *	Täglich, 0:00
@midnight	0 0 * * *	Wie @daily
@hourly	0 * * * *	Stündlich (Minute 0)

Anwendungsfälle für @reboot:

• Hintergrunddienste: Ohne systemd-Service starten
• Container-Setup: In Docker-Containern
• Persönliche Skripte: Nach Login oder Reboot
• Monitoring: Start einer Statusübertragung

Beispiel:

Wichtige Hinweise:

• Wird nur einmal beim Start ausgeführt
• Reihenfolge nicht garantiert (nicht warten auf Netzwerk)
• Besser für echte Dienste: systemd-Service mit After=network.target
• Bei Cron ohne Systemstart (Container): manchmal nicht ausgeführt

Ein systematischer Test ist die halbe Miete – so gehst du vor:

Schritt 1: Befehl manuell testen

Schritt 2: Umgebung simulieren

Schritt 3: Logging aktivieren

Schritt 4: Test mit kurzem Intervall

Schritt 5: Logs beobachten

Schritt 6: Exit-Code prüfen

Checkliste für Tests:

• Befehl funktioniert manuell ✓
• Absolute Pfade verwendet ✓
• Ausführungsrechte gesetzt ✓
• Umgebungsvariablen berücksichtigt ✓
• Output umgeleitet ✓
• Exit-Code geprüft ✓
• Logs überprüft ✓

Cron verwendet die Systemzeitzone des Servers – das ist oft eine böse Überraschung:

Warum ist das wichtig?

• Server in UTC: Cron läuft in UTC, nicht in lokaler Zeit
• Sommerzeit: Zeitumstellung kann Jobs doppelt oder gar nicht ausführen
• Container: Oft UTC als Standard
• Cloud: AWS, Azure, GCP – alles in UTC

Systemzeitzone prüfen:

Beispiel-Szenario:

Lösungsmöglichkeiten:

• Zeitzone anpassen: timedatectl set-timezone Europe/Berlin
• CRON_TZ verwenden: CRON_TZ=Europe/Berlin in der Crontab
• In UTC bleiben: Akzeptieren und Zeit entsprechend umrechnen
• Im Skript prüfen: [ $(date +%H) -eq 3 ] || exit 0

CRON_TZ Beispiel:

Tipp für Server-Admins: Server immer in UTC betreiben und Jobs in UTC planen. Das vermeidet Zeitumstellungs-Probleme. In der Anzeige dann für Nutzer umrechnen.

Wenn ein Job länger dauert als sein Intervall, kann er doppelt starten – das ist oft problematisch:

Beispiel: Job läuft alle 5 Minuten, dauert aber 10 Minuten → 2 Instanzen parallel.

Lösung 1: flock (empfohlen)

• -n: Kein Warten, sofort beenden wenn Lock gehalten
• Lock-Datei wird automatisch verwaltet
• Standard auf allen Linux-Systemen

Lösung 2: PID-Datei

Lösung 3: systemd-Service

Lösung 4: Cron mit Sekunden-Check

Vergleich der Lösungen:

Methode	Aufwand	Zuverlässigkeit
flock	Sehr gering	Sehr hoch
PID-Datei	Mittel	Hoch
systemd	Hoch	Sehr hoch
Timestamp-Check	Mittel	Mittel

Empfehlung: flock ist die einfachste und zuverlässigste Lösung für Cron-Jobs.