Wie man Cron-Jobs mit Crontab anzeigt und auflistet

Der crontab Befehl ist die primäre Schnittstelle zum Anzeigen, Bearbeiten und Verwalten geplanter Aufgaben im Unix-Cron-System. Um alle Cron-Jobs für den aktuell angemeldeten Benutzer aufzulisten, führen Sie crontab -l in einem beliebigen Terminal aus. Für Root- oder systemweite Jobs prüfen Sie /etc/crontab, /etc/cron.d/ und /var/spool/cron/crontabs/ direkt.

Cron ist das Rückgrat der Aufgabenautomatisierung auf Linux- und Unix-ähnlichen Systemen. Ob Sie nächtliche Datenbank-Dumps in einer VPS Hosting-Umgebung ausführen, Logs auf einem Dedicated Server rotieren oder SSL-Zertifikate automatisch über Certbot erneuern – zu verstehen, wie man jeden geplanten Job auf einer Maschine prüft und auflistet, ist eine unverzichtbare Sysadmin-Fähigkeit. Dieser Leitfaden deckt jede Schicht des Cron-Stacks ab – Benutzer-Crontabs, System-Crontabs, Drop-in-Verzeichnisse und den Spool – zusammen mit realen Fallstricken, über die selbst erfahrene Ingenieure stolpern.

Was ist Crontab und wie funktioniert das Cron-System

Crontab (kurz für „cron table”) ist eine benutzerspezifische Konfigurationsdatei, die dem crond-Daemon mitteilt, welche Befehle wann ausgeführt werden sollen. Jedes Benutzerkonto auf einem System – einschließlich root – kann eine unabhängige Crontab pflegen. Der Daemon liest diese Dateien beim Start und nach jeder Bearbeitung und führt dann Jobs gemäß ihren Zeitangaben aus.

Das Cron-Ökosystem auf einer modernen Linux-Distribution besteht aus mehreren verschiedenen Schichten:

• Benutzer-Crontabs — verwaltet über crontab -e und gespeichert in /var/spool/cron/crontabs/ (Debian/Ubuntu) oder /var/spool/cron/ (RHEL/CentOS)
• System-Crontab — die /etc/crontab-Datei, die ein zusätzliches user-Feld pro Eintrag enthält
• Drop-in-Verzeichnis — /etc/cron.d/, wo Pakete ihre eigenen Job-Definitionen installieren
• Run-parts-Verzeichnisse — /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, /etc/cron.monthly/, die ausführbare Skripte anstelle von Crontab-Syntaxdateien enthalten
• Anacron — eine Ergänzung zu Cron, die Jobs auf Maschinen verwaltet, die nicht rund um die Uhr laufen, und dabei aus /etc/anacrontab liest

Zu verstehen, in welcher Schicht ein Job angesiedelt ist, ist bei der Prüfung eines Servers entscheidend, da crontab -l allein die Mehrheit der geplanten Aufgaben auf einem typischen Produktionssystem übersieht.

Crontab-Zeitfeld-Syntax

Jeder Crontab-Eintrag folgt einer festen Fünf-Feld-Zeitangabe vor dem Befehl:

* * * * *  command_to_execute
| | | | |
| | | | +----- day of the week  (0–7, Sunday = 0 or 7)
| | | +------- month            (1–12)
| | +--------- day of the month (1–31)
| +----------- hour             (0–23)
+------------- minute           (0–59)

Spezielle Syntax-Abkürzungen, die von den meisten Cron-Implementierungen unterstützt werden:

Die /etc/crontab– und /etc/cron.d/-Dateien fügen ein sechstes Feld hinzu — den Benutzernamen, unter dem der Befehl ausgeführt wird — zwischen der Zeitangabe und dem Befehl selbst.

Cron-Jobs auflisten: Alle Methoden erklärt

1. Eigene Benutzer-Cron-Jobs anzeigen

crontab -l

Dies gibt die Crontab für den Benutzer aus, der den Befehl ausführt. Wenn noch keine Crontab vorhanden ist, sehen Sie entweder eine leere Ausgabe oder die Meldung no crontab for <username> — beides ist normal.

Beispielausgabe:

# m  h   dom mon dow  command
0    0   *   *   *    /home/deploy/backup.sh
30   2   *   *   7    /home/deploy/scripts/cleanup.sh
15   */4 *   *   *    /usr/local/bin/health-check.sh >> /var/log/health.log 2>&1

In diesem Beispiel:

• backup.sh wird jeden Tag um Mitternacht ausgeführt
• cleanup.sh wird jeden Sonntag um 02:30 ausgeführt
• health-check.sh wird alle vier Stunden ab 00:15 ausgeführt, wobei sowohl stdout als auch stderr in eine Protokolldatei umgeleitet werden

Fallstrick: Ausgabeumleitung (>>, 2>&1) wird in Crontab-Einträgen häufig weggelassen. Ohne sie versucht Cron, die Ausgabe per sendmail an den lokalen Benutzer zu senden. Auf Servern ohne Mail Transfer Agent werden alle Ausgaben stillschweigend verworfen, was das Debuggen nahezu unmöglich macht. Leiten Sie immer um oder setzen Sie MAILTO="" am Anfang der Crontab.

2. Cron-Jobs eines anderen Benutzers auflisten

Mit sudo oder Root-Zugriff können Sie die Crontab eines beliebigen Benutzers einsehen:

sudo crontab -l -u john

Ersetzen Sie john durch den Zielbenutzernamen. Dies ist funktional identisch mit dem Lesen der rohen Spool-Datei, verwendet jedoch den korrekten Sperrmechanismus und ist daher dem direkten Dateizugriff immer vorzuziehen.

3. Alle Benutzer-Crontabs auf einmal auflisten

Auf einem Mehrbenutzer-Server ist das Iterieren über jedes Konto die einzige zuverlässige Methode, um ein vollständiges Bild zu erhalten:

for user in $(cut -f1 -d: /etc/passwd); do
    echo "=== Crontab for: $user ==="
    sudo crontab -l -u "$user" 2>/dev/null
done

Das 2>/dev/null unterdrückt die „no crontab for”-Meldungen für Benutzer ohne Crontab und hält die Ausgabe übersichtlich.

4. Die systemweite Crontab anzeigen

cat /etc/crontab

Eine typische Ausgabe auf einem Debian-basierten System:

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

# m  h  dom mon dow  user     command
17  *  *   *   *    root     cd / && run-parts --report /etc/cron.hourly
25  6  *   *   *    root     test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47  6  *   *   7    root     test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52  6  1   *   *    root     test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Beachten Sie den test -x /usr/sbin/anacron-Guard: Wenn Anacron installiert ist, werden diese run-parts-Aufrufe übersprungen und Anacron übernimmt die Verantwortung für tägliche, wöchentliche und monatliche Jobs. Dies ist eine häufige Quelle der Verwirrung, wenn Jobs scheinbar nicht planmäßig ausgeführt werden.

5. Jobs in /etc/cron.d/ auflisten

ls -la /etc/cron.d/

Um den Inhalt jeder Datei im Verzeichnis in einem Durchgang zu prüfen:

grep -v '^#|^$' /etc/cron.d/*

Dies entfernt Kommentarzeilen und Leerzeilen und zeigt nur aktive Job-Definitionen an. Paketmanager legen hier häufig Dateien ab — gängige Beispiele sind sysstat, logrotate-Überschreibungen und Monitoring-Agenten.

6. Das Cron-Spool-Verzeichnis direkt prüfen

ls -la /var/spool/cron/crontabs/

Auf RHEL, CentOS und Fedora lautet der Pfad /var/spool/cron/ ohne das crontabs-Unterverzeichnis. Um die rohe Spool-Datei eines bestimmten Benutzers zu lesen:

sudo cat /var/spool/cron/crontabs/username

Wichtig: Bearbeiten Sie Spool-Dateien niemals direkt mit einem Texteditor. Der crontab -e-Befehl verwendet Dateisperrung und validiert die Syntax, bevor die neue Datei installiert wird. Direkte Bearbeitungen können die Datei beschädigen oder in einem Zustand hinterlassen, in dem crond sie vollständig ignoriert.

7. Anacron-Jobs auflisten

Wenn das System Anacron für eine robuste Planung verwendet:

cat /etc/anacrontab

Anacron-Einträge verwenden eine andere Syntax — Periode in Tagen, Verzögerung in Minuten, Job-Bezeichner und Befehl — anstelle des standardmäßigen Fünf-Feld-Cron-Formats.

8. Systemd-Timer prüfen (moderne Alternative)

Auf systemd-basierten Distributionen werden viele Aufgaben, die historisch von Cron verwaltet wurden, jetzt von systemd-Timern übernommen. Diese erscheinen in keiner Crontab-Auflistung:

systemctl list-timers --all

Eine vollständige Server-Prüfung muss sowohl Cron- als auch systemd-Timer-Überprüfungen umfassen. Dies zu versäumen ist eine der häufigsten Lücken bei Sicherheits- und Compliance-Überprüfungen.

Vollständiges Cron-Audit: Ein-Schuss-Befehl

Für ein schnelles, umfassendes Audit aller geplanten Aufgaben auf einem System kombinieren Sie alle Quellen:

echo "=== /etc/crontab ===" && cat /etc/crontab
echo "=== /etc/cron.d/ ===" && ls /etc/cron.d/ && grep -rh '' /etc/cron.d/
echo "=== User crontabs ===" && for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -l -u "$u" 2>/dev/null && echo "  ^ user: $u"; done
echo "=== Systemd timers ===" && systemctl list-timers --all --no-pager

Cron-Jobs bearbeiten und verwalten

Um Ihre eigene Crontab im Standard-Editor des Systems zu öffnen ($VISUAL oder $EDITOR, mit Fallback auf vi):

crontab -e

Um die Crontab eines anderen Benutzers als Root zu bearbeiten:

sudo crontab -e -u username

Um alle Cron-Jobs für den aktuellen Benutzer zu entfernen (mit Vorsicht verwenden — dies ist ohne Backup nicht rückgängig zu machen):

crontab -r

Um eine Crontab vor Änderungen zu sichern:

crontab -l > ~/crontab_backup_$(date +%F).txt

Sichern Sie immer vor dem Bearbeiten. Es gibt kein eingebautes Rückgängigmachen in crontab -e.

Cron vs. Systemd-Timer: Funktionsvergleich

Für unkomplizierte, zeitbasierte Automatisierung auf jedem Unix-System — einschließlich Legacy-Umgebungen und Containern — bleibt Cron die portabelste und betrieblich einfachste Wahl. Systemd-Timer sind überlegen, wenn Sie Abhängigkeitsreihenfolge, zuverlässige Ausführung verpasster Jobs oder strukturierte Protokollausgabe benötigen.

Häufige Crontab-Auflistungsbefehle: Kurzübersicht

Reale Fallstricke und Sonderfälle

Umgebungsvariablen werden nicht vererbt. Cron führt Jobs in einer minimalen Shell-Umgebung aus. Variablen wie PATH, HOME und LANG, die in Ihrer .bashrc oder .profile gesetzt sind, sind nicht verfügbar. Verwenden Sie immer absolute Pfade für Befehle und Binärdateien oder definieren Sie PATH explizit am Anfang der Crontab.

Die MAILTO-Variable steuert das Ausgabe-Routing. Setzen Sie MAILTO="", um die Ausgabe zu verwerfen, oder MAILTO="admin@example.com", um sie an eine bestimmte Adresse weiterzuleiten. Ohne einen konfigurierten MTA verursacht unbehandelte Ausgabe stille Fehler.

Berechtigungen für Skripte sind wichtig. Ein Skript, das interaktiv einwandfrei läuft, kann unter Cron fehlschlagen, wenn es nicht ausführbar ist (chmod +x) oder wenn es auf Dateien verweist, die der Cron-Benutzer nicht lesen kann.

Überlappende Job-Ausführung. Wenn ein Job länger dauert als sein Intervall, werden mehrere Instanzen gleichzeitig ausgeführt. Verwenden Sie eine Lock-Datei oder flock, um dies zu verhindern:

0 * * * * /usr/bin/flock -n /tmp/myjob.lock /home/user/long-running-job.sh

Zeitzonen-Bewusstsein. Cron verwendet standardmäßig die Systemzeitzone. Auf Servern mit UTC als Systemuhr — was auf VPS Hosting– und Dedicated Servern gängige Praxis ist — stellen Sie sicher, dass Ihre geplanten Zeiten den Offset berücksichtigen. Einige Cron-Implementierungen unterstützen eine CRON_TZ-Variable pro Crontab.

Crontab-Syntaxvalidierung. Bevor Sie einen neuen Crontab-Eintrag in der Produktion einsetzen, validieren Sie den Ausdruck mit einem Tool wie crontab.guru, um zu bestätigen, dass der Zeitplan Ihrer Absicht entspricht.

Cron-Job-Protokollierung und Debugging

Standardmäßig protokolliert Cron die Job-Ausführung in Syslog. Um aktuelle Cron-Aktivitäten anzuzeigen:

grep CRON /var/log/syslog | tail -50

Auf systemd-basierten Systemen:

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

Wenn ein Job nicht ausgeführt wird, prüfen Sie:

1. Der Cron-Daemon ist aktiv: systemctl status cron (oder crond auf RHEL-basierten Systemen)
2. Das Skript ist ausführbar und der Pfad ist korrekt
3. Die Zeitfelder sind syntaktisch gültig
4. Die Ausgabe wird nicht stillschweigend verworfen — fügen Sie vorübergehend >> /tmp/job.log 2>&1 hinzu
5. Der Benutzer, der den Job ausführt, hat die Berechtigung, den Befehl auszuführen

Bei der Verwaltung komplexer Automatisierungs-Stacks auf einem VPS mit cPanel bietet cPanel eine grafische Cron-Jobs-Oberfläche im Bereich „Erweitert”, die direkt in die Crontab des Benutzers schreibt. Über cPanel hinzugefügte Jobs sind mit crontab -l vollständig sichtbar und verhalten sich identisch zu manuell hinzugefügten Einträgen.

Entscheidungsmatrix: Welche Cron-Schicht verwenden

Praktische Schlüssel-Checkliste

• Führen Sie crontab -l aus, um Ihre eigenen Jobs zu prüfen; verwenden Sie das for-Schleifenmuster, um jeden Benutzer auf einem Multi-Tenant-Server zu prüfen.
• Prüfen Sie immer /etc/crontab, /etc/cron.d/ und systemctl list-timers --all — crontab -l allein liefert ein unvollständiges Bild.
• Verwenden Sie absolute Pfade für alle Befehle und Binärdateien in Crontab-Einträgen.
• Setzen Sie MAILTO="" oder leiten Sie die Ausgabe explizit um, um stille Fehler auf Servern ohne MTA zu verhindern.
• Sichern Sie Ihre Crontab mit crontab -l > backup.txt vor jeder Bearbeitungssitzung.
• Verwenden Sie flock, um die gleichzeitige Ausführung lang laufender Jobs zu verhindern.
• Prüfen Sie auf systemd-Systemen journalctl -u cron, anstatt sich ausschließlich auf /var/log/syslog zu verlassen.
• Validieren Sie neue Zeitausdrücke mit einem Online-Cron-Ausdruckstester, bevor Sie sie in der Produktion einsetzen.
• Berücksichtigen Sie UTC vs. lokale Zeitzone auf Cloud- und VPS Hosting-Instanzen.
• Für E-Mail-Hosting-Server oder jede Infrastruktur, bei der Jobs geschäftskritisch sind, implementieren Sie externes Monitoring (z. B. Healthcheck-Pings), um stille Cron-Fehler zu erkennen.

FAQ

Wie liste ich alle Cron-Jobs für jeden Benutzer auf einem Linux-Server auf?

Iterieren Sie über /etc/passwd und rufen Sie sudo crontab -l -u <user> für jedes Konto auf, wobei „no crontab”-Fehler mit 2>/dev/null unterdrückt werden. Prüfen Sie zusätzlich /etc/crontab, /etc/cron.d/ und führen Sie systemctl list-timers --all aus, um systemweite und systemd-verwaltete Jobs zu erfassen.

Warum zeigt crontab -l nichts an, obwohl Jobs ausgeführt werden?

Die Jobs sind wahrscheinlich in /etc/crontab, einer Datei innerhalb von /etc/cron.d/ oder als systemd-Timer definiert — keines davon ist über crontab -l sichtbar. Dieser Befehl zeigt nur die persönliche Crontab des aufrufenden Benutzers, die im Spool-Verzeichnis gespeichert ist.

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

Beide verwenden dieselbe Sechs-Feld-Syntax (einschließlich des Benutzernamenfeldes) und werden vom System-Cron-Daemon gelesen. /etc/crontab ist eine einzelne monolithische Datei für die manuelle Systemadministration. /etc/cron.d/ ist ein Drop-in-Verzeichnis, in dem einzelne Pakete oder Dienste ihre eigenen Job-Dateien installieren, wodurch diese isoliert und einfacher unabhängig verwaltet oder entfernt werden können.

Wie verhindere ich, dass ein Cron-Job mehrere überlappende Instanzen ausführt?

Umschließen Sie den Befehl mit flock -n /tmp/lockfile.lock, um eine nicht-blockierende exklusive Sperre zu erwerben. Wenn eine vorherige Instanz noch läuft, beendet sich der neue Aufruf sofort, ohne den Befehl auszuführen, und verhindert so Ressourcenkonflikte und Datenbeschädigung.

Wo werden Cron-Job-Protokolle gespeichert und wie debugge ich einen Job, der nicht ausgeführt wird?

Auf den meisten Systemen protokolliert Cron in /var/log/syslog (filtern mit grep CRON) oder über Journald (journalctl -u cron). Zum Debuggen hängen Sie vorübergehend >> /tmp/debug.log 2>&1 an den Job-Befehl an, um alle Ausgaben zu erfassen, überprüfen Sie, ob das Skript ausführbar ist, bestätigen Sie, dass der Daemon mit systemctl status cron läuft, und validieren Sie den Zeitausdruck unabhängig.