cron führt deinen Job nicht aus oder meldet 'command not found'? cron startet mit fast leerem PATH. So findet der Job seine Programme wieder.
Aufwand:
ca. 10 Min.
Voraussetzung:
Terminal, Editor
Das Symptom
Der Job funktioniert, wenn du ihn im Terminal von Hand startest – tadellos. Als
cron-Eintrag aber passiert: nichts. Keine Ausgabe, keine Datei, kein Effekt. Und
falls doch eine Fehlermail kommt, steht dort das ewig gleiche
command not found für ein Programm, das sichtbar installiert ist.
Die „Layer 8“-Wahrheit
Der Klassiker, und fast immer ist es die Umgebung. Wenn du dich einloggst, laden
.bashrc und .profile und blasen deinen PATH auf /usr/local/bin,
~/.local/bin und was sonst noch. cron liest diese Dateien nicht. Es setzt
selbst nur ein spartanisches Grundgerüst an Variablen und lässt den Rest
weitgehend leer. Dein Skript läuft also nicht in „deiner“ Shell, sondern in
einer nackten Minimalumgebung – und findet dort schlicht die Programme nicht, die
außerhalb des mageren Standard-PATH liegen. Die Lösung ist unspektakulär:
Entweder du gibst überall absolute Pfade an (/usr/local/bin/tool statt tool),
oder du setzt oben in der crontab einen eigenen PATH. Und bevor du stundenlang
rätselst, ob der Job überhaupt lief: Ein Blick ins Log beantwortet das in
Sekunden – lief er nie, ist es die Zeitangabe; brach er ab, ist es die Umgebung.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Prüfen, ob der Job überhaupt läuft
Erst die Fakten: Lief der Job und brach ab, oder lief er nie? Die Protokolle verraten es. Bei systemd über journalctl, klassisch im syslog:
Der robusteste Fix: keinem Befehl vertrauen, dass er im PATH liegt. Volle Pfade angeben, so ist der Job unabhängig von der Umgebung. Den Pfad findest du mit 'which':
which mein-programm
# crontab-Zeile:
0 3 * * * /usr/local/bin/mein-programm
3.
PATH direkt im crontab setzen
Alternativ oben in der crontab einen brauchbaren PATH definieren. Er gilt dann für alle Jobs darunter:
Zum Debuggen die tatsächliche Umgebung des cron-Jobs in eine Datei schreiben und ansehen. So erkennst du sofort, wie karg PATH & Co. wirklich sind:
* * * * * env > /tmp/cron-env.txt 2>&1
5.
Prozentzeichen escapen
Enthält dein Befehl ein '%' (etwa aus 'date +%F'), maskiere jedes Prozentzeichen mit einem Backslash, sonst deutet cron es als Zeilenumbruch und der Befehl bricht ab.
Häufige Fragen (FAQ)
?Warum findet cron mein Programm nicht, obwohl es im Terminal läuft?
Weil cron eine andere, minimale Umgebung nutzt. Dein interaktives Terminal lädt Profildateien wie .bashrc oder .profile, die dein PATH um Verzeichnisse wie /usr/local/bin oder ~/.local/bin erweitern. cron lädt diese Dateien nicht und startet mit einem stark eingeschränkten PATH – Programme, die dort nicht liegen, gelten als 'command not found'.
?Wie sehe ich überhaupt, ob der Job lief?
Über die Systemprotokolle. Auf systemd-Systemen zeigt 'journalctl -u cron' (oder 'crond') die Ausführungen, klassisch stehen sie in /var/log/syslog. Fehlt jede Spur, lief der Job nie – meist wegen falscher Zeitangabe. Steht dort ein Fehler, lief er, brach aber ab. Ein MAILTO im crontab schickt dir die Fehlerausgabe zusätzlich per Mail.
?Warum bricht mein Job mit dem Datums-Prozentzeichen ab?
In der crontab hat '%' eine Sonderbedeutung: Es wird zu einem Zeilenumbruch in der Standardeingabe des Befehls. Kommandos wie 'date +%Y-%m-%d' laufen deshalb im crontab nur, wenn du jedes Prozentzeichen mit einem Backslash als '\%' schützt.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Homebrew installiert, aber 'zsh: command not found: brew' auf dem Mac? Auf Apple Silicon fehlt /opt/homebrew im PATH. So richtest du brew dauerhaft ein.
Heizung oder Licht schaltet beim Nachhausekommen nicht? Meist fehlt der App die Standortfreigabe im Hintergrund oder das System hat sie schlafen gelegt.
Routine oder Automatisierung startet nicht zuverlässig? Meist hakt der Auslöser, ein offline gegangenes Gerät oder die Cloud. So findest du die Ursache.