# Cron Deep Dive: Zeitgesteuerte Aufgaben professionell planen

TL;DR / Management Summary Trotz moderner Alternativen wie Systemd-Timern (Artikel 053) bleibt Cron das universelle Werkzeug für die zeitgesteuerte Ausführung von Skripten. Ob Backups, Datenbank-Wartung oder das Versenden von Log-Reports: Wer die Crontab-Syntax beherrscht, automatisiert seine Infrastruktur präzise. Ein Senior Admin weiß zudem, wie er Anacron nutzt, um sicherzustellen, dass Aufgaben auch nach einem System-Stillstand nachgeholt werden.

# 1. Einführung & Architektur

Der Dämon im Hintergrund.

Der crond Dämon wacht jede Minute auf und prüft die Tabellen in /var/spool/cron/ und /etc/cron.d/.

# Die Hierarchie (Mermaid)

graph TD
    A[crond Daemon] --> B[User Crontabs: /var/spool/cron/tabs/]
    A --> C[System Crontab: /etc/crontab]
    A --> D[Modular Configs: /etc/cron.d/]
    A --> E[Periodic Folders: cron.daily / hourly]
    F[User: crontab -e] --> B
    G[Admin: vi] --> D

# 2. Die Crontab Syntax

Fünf Sterne für die Zeit.

* * * * * Befehl

1. Minute: 0-59
2. Stunde: 0-23
3. Tag des Monats: 1-31
4. Monat: 1-12
5. Wochentag: 0-7 (0 und 7 sind Sonntag)

# Beispiele für die Praxis

# Jeden Montag um 05:00 Uhr morgens
0 5 * * 1 /usr/local/bin/weekly_cleanup.sh

# Alle 15 Minuten
*/15 * * * * /usr/local/bin/check_temp.sh

# Um 03:00 Uhr an jedem 1. des Monats
0 3 1 * * /usr/local/bin/monthly_report.sh

# 3. System-weite Automatisierung

Ordnung statt Chaos.

Nutzen Sie als Admin niemals die Crontab des Users Root (crontab -e). Nutzen Sie die Verzeichnisse:

• /etc/cron.daily/: Werfen Sie Skripte hier rein, wenn sie einmal am Tag laufen sollen (keine Zeitwahl möglich!).
• /etc/cron.d/: Erstellen Sie hier eigene Dateien für Ihre Applikationen.

  # /etc/cron.d/myapp
  # Minute Hour Day Month Week User Command
  0 2 * * * root /opt/myapp/bin/backup.sh

# 4. Day-2 Operations: Anacron

Gedächtnis für Server-Pausen.

Normaler Cron führt Aufgaben nicht aus, wenn der Server zum geplanten Zeitpunkt ausgeschaltet war. Anacron löst dies.

• Anacron merkt sich den letzten Ausführungstag in /var/spool/anacron/.
• Beim nächsten Booten prüft er, ob ein täglicher/wöchentlicher Job verpasst wurde und holt ihn nach.

# 5. Troubleshooting & “War Stories”

Wenn die Automatik schläft.

# Story 1: “Die leere Umgebung”

Symptom: Ein Skript funktioniert manuell aufgerufen perfekt, schlägt aber via Cron fehl mit command not found. Ursache: Cron lädt keine User-Profile. Der $PATH ist oft nur /usr/bin:/bin. Lösung: Definieren Sie den Pfad am Anfang der Crontab oder nutzen Sie absolute Pfade: PATH=/usr/local/bin:/usr/bin:/bin

# Story 2: “Das volle Mail-Postfach”

Symptom: Der lokale Root-User hat hunderte Mails von Cron. Die Partition /var/spool/mail läuft voll. Ursache: Cron sendet den Output jedes Skripts per E-Mail an den Besitzer. Lösung: Leiten Sie den Output in ein Logfile oder ins Nirgendwo um: * * * * * /script.sh > /dev/null 2>&1. Oder nutzen Sie MAILTO="" am Anfang der Datei.

# 6. Fazit & Empfehlung

• Wartung: Nutzen Sie crontab -l, um die Liste Ihrer geplanten Aufgaben regelmäßig zu auditieren.
• Best Practice: Fügen Sie am Ende jedes Skripts eine Log-Meldung hinzu, damit Sie im Syslog sehen, wann Cron es gestartet hat.
• Wahl: Nutzen Sie Cron für einfache Intervalle. Nutzen Sie Systemd-Timer für komplexe Abhängigkeiten (z.B. “Nur starten, wenn Datenbank-Dienst bereit ist”).

# Anhang: Cheatsheet