crontab in Linux: Syntax, PATH-Regeln und Log-Prüfung

Der Befehl crontab plant wiederkehrende Hintergrundjobs auf Linux-Systemen über den cron-Daemon. Für eine zuverlässige Aufgabenautomatisierung müssen Benutzertabellen mit crontab -e bearbeitet, fünf Zeitfelder definiert und absolute Pfade zu Binärdateien angegeben werden, um Ausführungsfehler durch die reduzierte Standard-Shell-Umgebung von cron zu vermeiden.

Die fünfzeitige Syntax in crontab -e

Die Cron-Tabelle verarbeitet Direktiven anhand von fünf zeitlichen Parametern, gefolgt von der vom Betriebssystem ausgeführten Befehlszeile. Die genaue Syntax lautet sequenziell von links nach rechts: Minute (0-59), Stunde (0-23), Tag des Monats (1-31), Monat (1-12) und Wochentag (0-7, wobei sowohl 0 als auch 7 für Sonntag stehen).

Um Cron-Direktiven für das aktive Systemkonto zu bearbeiten, rufen Sie das standardmäßige interaktive Konfigurationswerkzeug auf:

crontab -e

Innerhalb dieser Konfigurationsdatei kennzeichnen Sternchen Platzhalter für jede Zeiteinheit, Kommas trennen einzelne Werte, Bindestriche definieren inklusive Bereiche und Schrägstriche bestimmen Schrittintervalle. Bei der Verwaltung dieser Konfigurationen von Mobilgeräten aus stellen Werkzeuge wie die Spezialtastatur in termi1 für iOS und Android fehlende Tasten wie Esc, Ctrl, Pfeiltasten und Tab bereit, was Bearbeitungen in nano oder Vim vereinfacht.

# Run database backups from Monday through Friday at 03:30
30 3 * * 1-5 /usr/local/bin/backup-cleanup.sh

# Run an external health check request every 15 minutes
*/15 * * * * /usr/bin/curl -fsS https://example.com/healthcheck

Beheben der reduzierten PATH-Umgebung in crontab

Der cron-Daemon lädt niemals interaktive Umgebungsdateien wie ~/.bashrc, ~/.zshrc oder /etc/profile. Bei Standard-Linux-Installationen ist die standardmäßige PATH-Variable unter cron strikt auf /usr/bin:/bin gesetzt, was zu stillen Fehlern führt, wenn Skripte auf Binärdateien in /usr/local/bin, Benutzerverzeichnissen oder Anwendungsumgebungen verweisen.

Systemadministratoren nutzen drei Methoden, um Umgebungsdiskrepanzen in crontab zu beheben:

1. Absolute Pfade verwenden für alle Systemprogramme, indem /usr/local/bin/node oder /usr/bin/python3 anstelle reiner Befehlsnamen aufgerufen werden.
2. Die PATH-Variable definieren ganz oben in der crontab-Konfigurationsdatei vor der Definition von Jobs.
3. Die Ausführungs-Shell angeben – explizit über SHELL=/bin/bash, um Dialektdiskrepanzen mit /bin/sh zu vermeiden.

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

0 2 * * * backup-database --all

Umleiten von stdout und stderr zur Erfassung von Cron-Ausgaben

Der cron-Daemon versucht, jede von geplanten Prozessen erzeugte Ausgabe über den lokalen Mail Transport Agent (MTA) an den lokalen Benutzer weiterzuleiten. Fehlt auf dem Remote-Rechner ein funktionierender lokaler Mail-Agent wie Postfix, werden alle Laufzeitprotokolle und kritischen Fehlerausgaben stillschweigend verworfen.

Um Aufgabenergebnisse zu prüfen und Probleme zu diagnostizieren, müssen Sie die Standardausgabe (Dateideskriptor 1) und den Standardfehler (Dateideskriptor 2) in eine explizite Ziel-Protokolldatei im Dateisystem umleiten:

0 4 * * * /usr/local/bin/sync-storage.sh >> /var/log/sync-storage.log 2>&1

Der Umleitungsoperator >> hängt Laufzeittext an, ohne vorherige Protokolleinträge zu kürzen, während der Ausdruck 2>&1 stderr mit stdout zusammenführt. Bei der Fehlerbehebung von Servern über einen mobilen Client können Sie diese Ziel-Protokolldateien direkt über einen integrierten SFTP-Browser einsehen oder herunterladen, ohne Ihre Terminalsitzung zu schließen.

Überprüfen der Job-Ausführung mit journalctl -u cron

Systemd zeichnet jeden cron-Aufrufzeitstempel und Ausführungsstatus im zentralen Systemjournal auf. Die Service-Unit heißt auf Debian- und Ubuntu-Distributionen cron, während RHEL- und Fedora-Systeme sie unter dem Namen crond führen.

Um zu bestätigen, ob der Planungsdienst Ihre Aufgabe im erwarteten Intervall ausgelöst hat, fragen Sie das zentrale Journal über systemd ab:

# On Debian, Ubuntu, and derivatives
journalctl -u cron -n 50 --no-pager

# On RHEL, Rocky Linux, and Fedora
journalctl -u crond -n 50 --no-pager

Um Ausführungsereignisse während geplanter Testphasen live zu verfolgen, führen Sie den Journal-Follower aus:

journalctl -u cron -f

Beim Überprüfen von Live-Logs über instabile Mobilfunkverbindungen stellt Mosh sicher, dass Ihre Terminalverbindung bei Wechseln zwischen WLAN und mobilen Daten reaktionsfähig bleibt, ohne Ihre interaktive Sitzung zu trennen.

Vergleich der crontab-Verwaltung: mobiles Terminal versus Desktop

Managing server automation across different client devices introduces distinct operational differences:

Wenn Zielsystemen zugängliche öffentliche Endpunkte oder offene Ports fehlen, können Administratoren den Datenverkehr sicher über Mesh-Overlay-Netzwerke wie Prialo leiten, um geschützt auf private Infrastruktur zuzugreifen.

Häufig gestellte Fragen

Warum schlägt ein crontab-Job fehl, wenn derselbe Befehl im interaktiven Terminal funktioniert?

crontab führt Befehle in einer minimalistischen Umgebung aus, die Shell-Profilvariablen nicht übernimmt. Wenn ein Skript von benutzerdefinierten Pfaden, Umgebungsvariablen oder Programmen außerhalb der Standard-Systemordner abhängt, schlägt es fehl, sofern keine absoluten Pfade angegeben oder explizite PATH-Zuweisungen im Kopf der crontab definiert werden.

Wie lassen sich aktuelle Benutzer-Cronjobs ohne Öffnen eines Editors anzeigen?

Der Befehl crontab -l gibt den Inhalt der crontab des aktuellen Benutzers direkt auf der Standardausgabe aus, ohne Sperren zu setzen oder Dateien zu ändern. Um geplante Aufgaben eines anderen bestimmten Benutzerkontos anzuzeigen, führen Sie crontab -u username -l mit Root-Rechten aus.

Wozu dient das spezielle Token @reboot in crontab?

Das Token @reboot ersetzt die standardmäßigen fünf Zeitfelder in einem crontab-Eintrag. Diese Anweisung weist den cron-Dienst an, das angegebene Skript oder den Binärbefehl genau einmal unmittelbar nach Abschluss des Bootvorgangs des Betriebssystems auf dem Server auszuführen.

Wo befinden sich Cron-Protokollmeldungen, wenn ein Server kein systemd nutzt?

Auf Linux-Systemen mit klassischen Syslog-Daemons und ohne aktives systemd journald befinden sich die protokollierten Ausführungsmeldungen von cron standardmäßig unter /var/log/syslog auf Debian- und Ubuntu-Systemen sowie in /var/log/cron bei Distributionen aus der Red-Hat-Familie.