Cron ist der zeitbasierte Aufgabenplaner, der seit Jahrzehnten Hintergrundaufgaben auf Unix-Systemen ausführt. Wenn ein Skript jede Nacht laufen, ein Backup stündlich starten oder ein Aufräumlauf jeden Montagmorgen erfolgen soll, ist Cron das klassische, verlässliche Werkzeug dafür. Unter Ubuntu 24.04 LTS ist der Cron-Daemon standardmäßig installiert und aktiviert, sodass Sie sofort Aufgaben planen können.

Diese Anleitung erklärt die crontab-Syntax Feld für Feld, zeigt praxisnahe Beispiele, demonstriert das Protokollieren von Ausgaben, damit Ihre Jobs nicht stillschweigend fehlschlagen, und erläutert, wann ein systemd-Timer die bessere Wahl ist. Alle Befehle zielen auf Ubuntu 24.04.

Voraussetzungen

• Ubuntu 24.04 LTS mit einem Benutzerkonto, das die zu planenden Aufgaben ausführen darf.
• sudo-Zugriff nur, wenn Sie die crontab eines anderen Benutzers oder einen systemweiten Zeitplan bearbeiten müssen.

Prüfen Sie, ob der Cron-Dienst läuft:

systemctl status cron

Sie sollten active (running) sehen. Ist er nicht aktiviert, schalten Sie ihn mit sudo systemctl enable --now cron ein.

Die crontab-Syntax verstehen

Jede Zeile einer crontab beschreibt einen geplanten Job mit fünf Zeitfeldern, gefolgt vom auszuführenden Befehl:

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

Ein Sternchen * bedeutet „jeder Wert“. Sie können außerdem Listen (1,15,30), Bereiche (1-5) und Schritte (*/10 für jede zehnte Einheit) verwenden.

Schritt 1: Eigene crontab bearbeiten

Öffnen Sie Ihre persönliche crontab im Standardeditor:

crontab -e

Beim ersten Mal fragt Ubuntu, welcher Editor verwendet werden soll; wählen Sie im Zweifel nano. Fügen Sie Jobs zeilenweise hinzu, speichern und schließen Sie. Aktuelle Jobs jederzeit auflisten:

crontab -l

Schritt 2: Praxisnahe Planungsbeispiele

Hier sind gängige Muster, die Sie direkt in Ihre crontab einfügen können:

# Backup-Skript taeglich um 02:30 ausfuehren
30 2 * * * /home/alice/scripts/backup.sh
Alle 15 Minuten synchronisieren
*/15 * * * * /usr/local/bin/sync-data.sh
Temp-Verzeichnis jeden Montag um 04:00 aufraeumen
0 4 * * 1 /usr/bin/find /tmp/cache -type f -mtime +7 -delete
Job am Ersten jedes Monats um Mitternacht
0 0 1 * * /home/alice/scripts/monthly-report.sh

Cron unterstützt zudem praktische Kürzel anstelle der fünf Felder:

@reboot   /home/alice/scripts/startup.sh
@daily    /home/alice/scripts/cleanup.sh
@hourly   /usr/local/bin/poll.sh

Schritt 3: Ausgabe erfassen und protokollieren

Standardmäßig wird alles, was ein Cron-Job auf stdout oder stderr ausgibt, an den lokalen Benutzer gemailt — was meist bedeutet, dass es verschwindet, wenn kein Mailsystem konfiguriert ist. Leiten Sie die Ausgabe daher immer in eine Logdatei um, um Fehler analysieren zu können:

30 2 * * * /home/alice/scripts/backup.sh >> /var/log/backup.log 2>&1

Dabei hängt >> stdout an die Logdatei an, und 2>&1 leitet stderr an dieselbe Stelle um. Um zu beobachten, was Cron selbst startet, prüfen Sie das System-Journal:

journalctl -u cron --since '1 hour ago'

Schritt 4: Auf Cron-Umgebung und PATH achten

Cron führt Jobs mit einer minimalen Umgebung aus, nicht mit Ihrer interaktiven Shell. Die häufigste Ursache für „läuft im Terminal, scheitert in Cron“ ist ein zu kurzer PATH. Verwenden Sie entweder absolute Pfade zu jeder Binärdatei oder setzen Sie die Umgebung am Anfang der crontab:

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO=alice@example.com

0 6 * * * backup-tool --full

Schritt 5: Systemweite und paketierte Cron-Jobs

Neben benutzerbezogenen crontabs bietet Ubuntu Systemorte für geplante Jobs. Skripte in diesen Verzeichnissen laufen automatisch:

/etc/cron.hourly/
/etc/cron.daily/
/etc/cron.weekly/
/etc/cron.monthly/

Für feinere Kontrolle mit Benutzerspalte bearbeiten Sie /etc/crontab oder legen eine Datei unter /etc/cron.d/ an. Diese System-crontabs haben ein sechstes Feld — den Benutzer, unter dem ausgeführt wird:

# m h dom mon dow user  befehl
0 3 * * *           root  /usr/local/bin/rotate-logs.sh

Verifizierung: beweisen, dass ein Job läuft

Warten Sie nicht bis 2 Uhr nachts, um zu merken, dass ein Job defekt ist. Planen Sie ihn vorübergehend für die nächste Minute und beobachten Sie das Log:

* * * * * /home/alice/scripts/backup.sh >> /tmp/cron-test.log 2>&1

Verfolgen Sie dann die Ausgabe:

tail -f /tmp/cron-test.log

Sobald bestätigt ist, dass er wie erwartet läuft und protokolliert, stellen Sie den Zeitplan auf die echte Uhrzeit zurück.

Cron vs. systemd-Timer

Cron ist ideal für einfache, periodische Jobs. Ein systemd-Timer ist die bessere Wahl, wenn Sie Folgendes brauchen: Reihenfolge-Abhängigkeiten zu anderen Diensten, korrektes Nachholen verpasster Läufe nach Ausfallzeiten (Persistent=true), Ressourcenlimits oder einheitliches Logging im Journal. Als Faustregel: Greifen Sie für schnelle periodische Skripte zu Cron und für Jobs, die eigentlich ein verwalteter Dienst sind, zu einem systemd-Timer. Unsere Anleitung zum Verwalten von systemd-Diensten mit systemctl behandelt das Erstellen von Units und Timern.

Fehlerbehebung und typische Stolperfallen

• Job läuft nie — prüfen Sie die Zeitfelder und bestätigen Sie mit systemctl status cron, dass Cron aktiv ist.
• Funktioniert manuell, scheitert in Cron — fast immer ein PATH- oder Umgebungsproblem; verwenden Sie absolute Pfade.
• Prozentzeichen verschluckt — in der crontab wird ein nicht maskiertes % zu einem Zeilenumbruch. Maskieren Sie es als % oder kapseln Sie den Befehl in einem Skript.
• Nirgends Ausgabe — Sie haben die Umleitung vergessen; fügen Sie >> logdatei 2>&1 hinzu.

Fazit

Sie verstehen nun die crontab-Syntax, können echte Jobs planen, deren Ausgabe erfassen, die klassische PATH-Falle vermeiden und wissen, wann ein systemd-Timer besser passt. Verlässliche Zeitplanung ist die Grundlage von Backups, Wartung und Automatisierung auf jedem Server. Wenn Sie solche Automatisierung über eine ganze Flotte skalieren, betreibt clouditiv die Orchestrierung für Sie auf einer souveränen, ISO 27001 / BSI C5-zertifizierten Private Cloud mit Ubuntu 24.04 + OpenStack 2025.2 — sehen Sie, wie wir das automatisierte Provisioning handhaben, oder gehen Sie mit der OpenStack-CLI einen Schritt weiter in Richtung cloud-nativer Automatisierung.