Warum Ihr Cron-Job nicht läuft: 5 häufige Ursachen

Warum Ihr Cron-Job nicht ausgeführt wird

Ein Cron-Job, der „nie ausgeführt wird“, wurde fast immer ausgeführt. Er lief in einer Umgebung, die nicht Ihrer Shell entspricht, schlug in der ersten Sekunde fehl, und die Meldung wurde an eine Stelle gesendet, die Sie nicht prüfen. Fünf Ursachen erklären fast alle solchen Meldungen: der Suchpfad, das Prozentzeichen, die falsche Crontab-Datei, die Ausgabe per E-Mail und ein Skript, das eine Anmeldesitzung voraussetzt.

cron ist ein Daemon (ein Hintergrunddienst), der Crontab-Dateien liest und Befehle nach einem Zeitplan startet. Er liest Ihre .bashrc nicht, öffnet kein Terminal, startet keine Login-Shell und informiert Sie nicht, wenn ein Befehl fehlschlägt. Jede der folgenden Ursachen ergibt sich aus diesen vier Tatsachen.

Arbeiten Sie sie in dieser Reihenfolge durch. Beginnen Sie mit der Frage, die allen anderen zugrunde liegt: Hat cron den Job überhaupt gestartet? „cron hat den Job nie gestartet“ und „der Job wurde gestartet und beendet“ sind unterschiedliche Probleme ohne gemeinsamen Zusammenhang. Beantworten Sie daher zuerst diese Frage.

Wurde der cron-Auftrag überhaupt ausgeführt?

Der Daemon hat je nach Distributionsfamilie einen anderen Unit-Namen. Prüfen Sie beide und lesen Sie anschließend das Log.

systemctl status cron
systemctl status crond
journalctl -u cron --since "2 hours ago"
journalctl -u crond --since "2 hours ago"

Debian und Ubuntu nennen die Unit cron. Fedora, Rocky und Alma nennen sie crond. Auf einem bestimmten System existiert nur einer dieser Namen. Daher ist es normal und kein Fehler, wenn einer der beiden Befehle eine unbekannte Unit meldet.

Lesen Sie die Einträge, die Ihr eigenes System geschrieben hat. Suchen Sie nicht nach einer aus einer Anleitung kopierten Zeile, da sich der Wortlaut zwischen den cron-Implementierungen und den Logging-Konfigurationen unterscheidet. Sie prüfen nur zwei Dinge: Gibt es in der Minute, die Ihr Zeitplan angibt, einen Eintrag? Und nennt dieser Eintrag Ihren Befehl? Ein Eintrag, der Ihren Befehl nennt, bedeutet, dass cron seinen Teil erledigt hat. Der Fehler liegt dann innerhalb des Befehls. Gibt es überhaupt keinen Eintrag, hatte cron Ihren Zeitplan nicht geladen. Das ist Ursache 3 weiter unten.

Einige Images leiten cron-Nachrichten über rsyslog in eine Datei statt in das Journal. Suchen Sie in /var/log nach einer Datei mit cron oder syslog im Namen und lesen Sie anschließend deren Ende.

ls -l /var/log
sudo tail -n 50 /var/log/syslog

Wenn weder die Unit noch das Log vorhanden ist, ist cron möglicherweise einfach nicht installiert. Minimale Cloud-Images und Container enthalten cron häufig nicht.

dpkg -l cron
rpm -q cronie
sudo apt install cron
sudo dnf install cronie
sudo systemctl enable --now cron

Ursache 1: cron kennt Ihr PATH nicht

Ihre interaktive Shell erstellt PATH aus /etc/profile, ~/.profile, ~/.bashrc und allen Dateien, die diese Dateien einbinden. Für einen cron-Job wird davon nichts ausgeführt. cron startet den Befehl mit einer eigenen, kurzen Umgebung. Deshalb wird ein Programm außerhalb der standardmäßigen Systemverzeichnisse nicht gefunden. Alles unter /usr/local/bin oder /opt, ein Versionsmanager für Programmiersprachen, eine virtuelle Python-Umgebung oder ein Go-Arbeitsbereich kommt dafür infrage. Der Job schlägt in der ersten Zeile fehl. Die Shell schreibt eine Fehlermeldung nach dem Muster "not found". Der genaue Wortlaut hängt davon ab, welche Shell den Befehl ausgeführt hat.

Ermitteln Sie den tatsächlichen Pfad jedes Befehls, den Ihr Job verwendet.

command -v docker
command -v node
readlink -f "$(command -v node)"

Schreiben Sie diese absoluten Pfade anschließend entweder direkt in den Job oder setzen Sie PATH einmal am Anfang der crontab.

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
0 3 * * * /usr/local/bin/mytool run

Ermitteln Sie diese Liste auf Ihrem eigenen System mit echo "$PATH". Entfernen Sie alle Einträge, die nur innerhalb einer interaktiven Sitzung vorhanden sind. Eine Regel ist hier entscheidend: cron ersetzt Variablen in diesen Zuweisungszeilen nicht. PATH=$PATH:/usr/local/bin speichert den Literaltext $PATH:/usr/local/bin. Dadurch enthält der Suchpfad des Jobs am Ende überhaupt kein nutzbares Verzeichnis. Schreiben Sie die vollständige Liste aus.

Ein Versionsmanager benötigt mehr als nur einen Pfad. nvm, pyenv, rbenv und asdf installieren über Ihre .bashrc entweder eine Shell-Funktion oder ein shims-Verzeichnis. Ein cron-Job liest diese Datei jedoch nie ein. Rufen Sie die versionierte Binärdatei über ihren absoluten Pfad auf oder binden Sie das Initialisierungsskript des Managers als erste Zeile in Ihr eigenes Skript ein.

Ursache 2: Das Prozentzeichen beendet Ihren Befehl

Im Befehlsfeld einer crontab ist % kein gewöhnliches Zeichen. Das erste nicht maskierte % beendet den Befehl. Alles danach wird dem Befehl als Standardeingabe übergeben, und jedes weitere % wird zu einem Zeilenumbruch. Das ist eine echte cron-Funktion, um einem Programm kurze Eingaben zuzuführen. Genau deshalb ist ein Dateiname mit Datumsstempel der klassische fehlerhafte crontab-Eintrag.

Schreiben Sie 0 3 * * * /usr/bin/tar -czf /srv/backups/site-$(date +%F).tar.gz /srv/site, sieht tar kein formatiertes Datum. cron schneidet die Zeile am ersten % ab. Dadurch erhält die Shell eine unvollständige Befehlsersetzung, und der Rest Ihrer Zeile kommt als Standardeingabe an. Maskieren Sie jedes Prozentzeichen mit einem Backslash.

0 3 * * * /usr/bin/tar -czf /srv/backups/site-$(date +\%F).tar.gz /srv/site

Zwei Ebenen lesen diese eine Zeile nacheinander. \% ist eine cron-Regel, die cron verarbeitet, bevor irgendetwas gestartet wird. $(date +\%F) ist eine Befehlsersetzung, die später von der Shell verarbeitet wird, die cron startet. Entscheidend ist, welche Ebene für welches Zeichen zuständig ist.

Die sicherere Vorgehensweise besteht darin, die Logik vollständig aus der crontab herauszuhalten. Legen Sie sie in ein Script. Dort hat das Prozentzeichen keine besondere Bedeutung.

#!/bin/bash
set -euo pipefail
stamp="$(date +%F)"
tar -czf "/srv/backups/site-${stamp}.tar.gz" /srv/site

Die crontab-Zeile enthält dann nur noch einen Pfad und eine Umleitung. Eine crontab, die Sie auf einen Blick lesen können, lässt sich auch leichter debuggen.

Ursache 3: Welche Crontab haben Sie bearbeitet?

Es gibt nicht nur eine Crontab. Es gibt mehrere Dateien mit unterschiedlichen Eigentümern und unterschiedlicher Feldanzahl. Ein in die falsche Datei eingetragener Job ist unsichtbar.

• crontab -e bearbeitet die Crontab des Benutzers, der den Befehl ausführt. sudo crontab -e bearbeitet die Crontab von root. Zwei Personen, die denselben Server untersuchen, lesen daher häufig zwei verschiedene Dateien.
• sudo crontab -l -u deploy listet die Crontab eines anderen Benutzers auf. Damit prüfen Sie, was für das Konto tatsächlich installiert ist, unter dem der Job laufen soll.
• /etc/crontab und jede Datei in /etc/cron.d enthalten zwischen Zeitplan und Befehl ein zusätzliches Feld: den Benutzer, unter dem der Job ausgeführt wird. Wenn Sie eine fünfteilige Zeile aus einer Benutzer-Crontab in /etc/cron.d einfügen, wird das erste Wort Ihres Befehls als Benutzername gelesen.
• Dateien in /etc/cron.d müssen aus Buchstaben, Ziffern, Unterstrichen und Bindestrichen bestehen. Eine Datei mit dem Namen backup.sh oder site.conf wird allein wegen ihres Namens übersprungen. Benennen Sie sie in backup um und prüfen Sie Ihr Log erneut.
• Dateien in /etc/cron.d sollten root gehören und dürfen weder für die Gruppe noch für andere Benutzer beschreibbar sein. ls -l /etc/cron.d zeigt Ihnen beide Eigenschaften gleichzeitig.
• In /etc/cron.daily und den zugehörigen Verzeichnissen abgelegte Skripte müssen ebenfalls der gleichen Namensregel entsprechen und das Execute-Bit gesetzt haben. Ein fehlendes Execute-Bit führt dazu, dass der Job stillschweigend übersprungen wird.
• /etc/cron.allow und /etc/cron.deny legen fest, wer überhaupt eine Crontab installieren darf. Wenn eine dieser Dateien auf Ihrem Server vorhanden ist, lesen Sie sie, bevor Sie davon ausgehen, dass Ihr Benutzer eine Crontab anlegen darf.

Installieren Sie eine Benutzer-Crontab mit dem Befehl crontab, statt die Spool-Datei von Hand zu bearbeiten, weil crontab die Datei vor der Installation prüft. Lesen Sie nach dem Speichern die Ausgabe des Befehls. Wenn der Befehl die Datei ablehnt, bleibt die vorherige Version aktiv und Ihre Änderung wird nicht übernommen. Das sieht genau so aus, als würde cron Sie ignorieren.

Der Eigentümer bestimmt auch die Berechtigungen. Ein Job in der Crontab von root erstellt Dateien, in die die Anwendung möglicherweise nicht schreiben kann. Ein Job in der Crontab eines normalen Benutzers kann kein Verzeichnis lesen, auf das nur root Zugriff hat. Stimmen Sie den Eigentümer auf die Aufgabe ab: Die Wartung einer Anwendung gehört zum Konto dieser Anwendung. Das ist der Grundgedanke hinter WordPress wp-cron durch einen System-Cronjob ersetzen. Der Modus der von Ihrem Job erstellten Dateien ergibt sich aus der geerbten umask. Auch dieser Wert entspricht nicht der umask Ihrer Shell. Daher lohnt sich wie umask Dateiberechtigungen festlegt, wenn die Ausgabe eines Jobs nicht lesbar ist.

Ursache 4: Die Ausgabe ging an Mail, die niemand liest

cron sammelt alles, was ein Job auf die Standardausgabe und die Standardfehlerausgabe schreibt. Wenn der Job überhaupt etwas ausgibt, übergibt cron diesen Text an das lokale Mailsystem. Die Nachricht geht an den Besitzer der Crontab oder an das, was MAILTO angibt. Auf einem schlanken VPS ist normalerweise kein MTA (Mail Transfer Agent) installiert. Daher stellt niemand die Nachricht zu. Der Fehler war kurz vorhanden und verschwand dann. Genau deshalb wirkt ein fehlerhafter Job still.

Leiten Sie die Ausgabe stattdessen in eine Datei um, die Sie kontrollieren.

0 3 * * * /usr/local/sbin/backup-site.sh >> /var/log/backup-site.log 2>&1

>> hängt die Standardausgabe an die Datei an. 2>&1 leitet die Standardfehlerausgabe an das Ziel weiter, auf das die Standardausgabe aktuell zeigt. Deshalb muss es nach der Umleitung stehen. In der umgekehrten Reihenfolge, also als 2>&1 >> file, behält die Standardfehlerausgabe ihr ursprüngliches Ziel. Der gesuchte Fehler erreicht dann genau nicht die Datei.

Das Journal ist ein weiteres geeignetes Ziel. logger schreibt unter einem von Ihnen festgelegten Tag in syslog.

0 3 * * * /usr/local/sbin/backup-site.sh 2>&1 | logger -t backup-site

Lesen Sie die Ausgabe mit journalctl -t backup-site wieder aus. Dadurch steht die Ausgabe des Jobs direkt neben den Cron-Einträgen. So lässt sich der zeitliche Ablauf leicht nachvollziehen. Wenn Sie außerdem protokollieren müssen, welche Person welchen Befehl auf dem Server ausgeführt hat, ist dafür ein separates System erforderlich. Benutzerbefehle auf Ihrem Server auditieren beschreibt dieses Vorgehen.

MAILTO="" am Anfang einer Crontab deaktiviert Mail für die darunter aufgeführten Jobs. Das Setzen von MAILTO auf eine echte Adresse hilft nur, wenn ein funktionierendes MTA vorhanden ist. Prüfen Sie daher zuerst, dass Mail den Server tatsächlich verlässt.

Eine Regel beim Debugging: Hängen Sie niemals > /dev/null 2>&1 an. Diese Zeile ist in jeder Crontab besonders verbreitet und verwirft den einzigen Nachweis, den Sie haben. Fügen Sie sie später wieder ein, wenn der Job funktioniert.

Ursache 5: Das Skript setzt eine Umgebung voraus, die cron ihm nicht bereitstellt

Sobald der Befehl gefunden und seine Ausgabe erfasst wurde, fehlt nur noch alles, was Ihre Sitzung Ihnen automatisch bereitstellt.

• Die Shell ist möglicherweise nicht bash. Prüfen Sie dies mit ls -l /bin/sh. Unter Debian und Ubuntu zeigt es auf dash. Daher schlagen der Test mit doppelten eckigen Klammern, Arrays und source mit einem Syntaxfehler fehl. Geben Sie dem Skript eine #!/bin/bash-Zeile und rufen Sie das Skript damit auf, oder setzen Sie SHELL am Anfang der crontab.
• Das Arbeitsverzeichnis ist nicht das Verzeichnis, in dem Sie sich zuvor befanden. Verwenden Sie überall absolute Pfade oder wechseln Sie mit cd in der ersten Zeile des Skripts in dieses Verzeichnis. Ein relativer Pfad ist der häufigste einzelne Grund dafür, dass ein Job „funktioniert, wenn ich ihn von Hand ausführe“.
• Das Locale entspricht nicht dem Ihrer Sitzung. Alles, was ein Datum oder eine Zahl formatiert oder Text sortiert, kann unter einem anderen LANG eine andere Ausgabe erzeugen. Wenn ein späterer Schritt diese Ausgabe verarbeitet, setzen Sie das Locale im Skript, statt darauf zu hoffen.
• Es gibt kein TTY (Terminal). Ein Befehl, der eine Bestätigung anfordert, einen Editor öffnet oder einen Fortschrittsbalken anzeigt, kann hängen bleiben oder beendet werden. Verwenden Sie das entsprechende nicht-interaktive Flag des Tools.
• Es gibt keinen SSH-Agenten. SSH_AUTH_SOCK ist in der Umgebung von cron nicht gesetzt. Daher schlägt ein ssh- oder rsync-Befehl, der aufgrund Ihres geladenen Agenten funktioniert hat, nun bei der Authentifizierung fehl. Geben Sie dem Job einen eigenen Schlüssel, der dem Benutzer des Jobs gehört.
• Es gibt keinen Benutzer-Session-Bus. Daher schlägt systemctl --user aus einem cron-Job fehl, bis XDG_RUNTIME_DIR gesetzt ist. Eine System-Unit ist die bessere Lösung.

Unter Fedora, Rocky und Alma gibt es einen weiteren möglichen Verursacher. SELinux schränkt cron-Jobs ein. Daher wird ein Job, der auf einen Pfad mit einem unerwarteten Label zugreift, verweigert, selbst wenn die Dateiberechtigungen korrekt aussehen. Prüfen Sie mit sudo ausearch -m avc -ts recent auf Verweigerungen und lesen Sie SELinux-Grundlagen für einen Server, bevor Sie SELinux deaktivieren.

Die einminütige Prüfung, die die Umgebung von cron sichtbar macht

Raten Sie nicht länger, welche Umgebungsvariablen cron verwendet, sondern lesen Sie sie aus. Schreiben Sie ein Skript, das alle Werte ausgibt, planen Sie es für die Ausführung jede Minute ein, warten Sie kurz und lesen Sie anschließend die Datei.

cat > /home/deploy/cron-probe.sh <<'EOF'
#!/bin/bash
echo "=== probe ==="
date -Is
pwd
id
echo "SHELL=$SHELL"
echo "LANG=$LANG"
command -v node || echo "node is not on this PATH"
env | sort
EOF
chmod +x /home/deploy/cron-probe.sh

Fügen Sie der Crontab des Benutzers, unter dem der eigentliche Auftrag ausgeführt wird, eine Zeile hinzu. Verwenden Sie auf beiden Seiten absolute Pfade.

* * * * * /home/deploy/cron-probe.sh >> /home/deploy/cron-probe.log 2>&1

Warten Sie eine Minute und lesen Sie anschließend /home/deploy/cron-probe.log. Vergleichen Sie die Ausgabe mit denselben Befehlen, die Sie in Ihrer eigenen Shell ausführen. Die Zeile PATH, das Arbeitsverzeichnis und die Locale erklären den Fehler meist bereits. Beachten Sie zwei Details dieser Konfiguration: Die Prozentzeichen stehen im Skript, wo die Regel von cron nicht gilt, und der Pfad der Protokolldatei ist für den Benutzer des Auftrags beschreibbar.

Löschen Sie diese Crontab-Zeile, sobald Sie die Ursache gefunden haben. Ein Auftrag, der jede Minute ausgeführt wird und an eine Datei anhängt, kann einen kleinen Datenträger füllen. Das geschieht außerdem unbemerkt.

Ist der Zeitplan der gewünschte?

Eine Benutzer-Crontab-Zeile beginnt mit fünf Feldern: Minute, Stunde, Tag des Monats, Monat, Wochentag. Zwei davon interagieren auf eine Weise, die häufig zu Überraschungen führt.

Wenn Tag des Monats und Wochentag beide eingeschränkt sind, also keiner von beiden * ist, führt cron den Job aus, sobald eines der beiden Felder übereinstimmt. 0 0 13 * 5 bedeutet nicht „Freitag, der 13.“. Der Job läuft um Mitternacht am 13. jedes Monats und um Mitternacht an jedem Freitag. Für einen einzelnen bestimmten Tag lassen Sie eines der beiden Felder auf * und prüfen das andere im Skript.

cron verwendet die Systemzeitzone. Viele VPS-Images sind auf UTC (koordinierte Weltzeit) eingestellt. Ein für 03:00 geplanter Job läuft dann um 03:00 UTC. Das kann mitten in Ihrem Nachmittag sein. timedatectl zeigt die tatsächlich verwendete Zeitzone Ihres Systems an. Lesen Sie den Wert auf Ihrem System aus, statt anzunehmen, dass er der Zeitzone Ihres Laptops entspricht.

Zwei weitere Fallen bei Zeitplänen sollten Sie kennen. @reboot wird ausgelöst, wenn cron selbst startet. Das ist nicht derselbe Zeitpunkt, zu dem das Netzwerk bereit ist. Ein Job, der DNS oder einen entfernten Host benötigt, kann daher beim Booten fehlschlagen und bei jedem späteren manuellen Start erfolgreich sein. Außerdem verhindert nichts, dass ein langsamer Job erneut startet, während die vorherige Instanz noch läuft. Sichern Sie ihn mit einer Sperre.

*/5 * * * * /usr/bin/flock -n /tmp/backup-site.lock /usr/local/sbin/backup-site.sh >> /var/log/backup-site.log 2>&1

flock -n beendet den Lauf sofort, wenn die Sperre bereits gehalten wird. Der überlappende Lauf wird dadurch beendet, statt zusätzlich zum ersten Lauf zu starten.

Wenn ein systemd-Timer das bessere Werkzeug ist

cron ist für eine Aufgabe gut geeignet: einen Befehl zu einem bestimmten Zeitpunkt auszuführen. In allen anderen Bereichen ist cron eingeschränkt. Ein Timer schreibt ohne Umleitung in das Journal, stellt einen später abfragbaren Exit-Status bereit, ermöglicht die Reihenfolge gegenüber network-online.target und kann eine zufällige Verzögerung verwenden. Dadurch starten nicht hundert Server in derselben Sekunde. Wenn Ihr Job eine dieser Funktionen benötigt, ist ein systemd-Service und Timer auf einem VPS weniger Arbeit, als eine crontab-Zeile zu verteidigen. Beim Schreiben der Service-Datei müssen Sie eine Frage beantworten, die cron nie stellt: Woran erkennt die Unit, dass die Arbeit tatsächlich begonnen hat? Lesen Sie deshalb zuerst was Type= für simple-, forking- und notify-Units bedeutet. Ein Script, das sich unter dem Standardtyp selbst in einen Daemon-Prozess umwandelt, lässt die Unit aktiv erscheinen, obwohl kein Prozess mehr dahintersteht. Auch das Wiederholungsverhalten gehört hierher, denn systemd-Neustartrichtlinien legen fest, was nach einem Fehler geschieht. cron bietet darauf überhaupt keine Antwort.

Verwenden Sie cron weiterhin für kleine Jobs. Verschieben Sie alles mit Abhängigkeiten oder einer Wiederholungsrichtlinie auf einen Timer. Beide können auf demselben Server ausgeführt werden. Sie müssen diese Umstellung daher nicht in einer Sitzung abschließen.

FAQ

Warum funktioniert mein Cronjob manuell, schlägt aber über cron fehl?

Ihre Shell und die Umgebung von cron unterscheiden sich. Ihre Login-Shell liest /etc/profile und ~/.bashrc ein. Diese setzen PATH, die Locale und Ihre Agent-Variablen. cron startet den Befehl ohne diese Einstellungen, aus einem anderen Arbeitsverzeichnis und manchmal mit einer anderen Shell. Verwenden Sie für jeden Befehl absolute Pfade. Setzen Sie die benötigten Variablen am Anfang der Crontab oder im Skript. Richten Sie außerdem einen Testjob mit einer Laufzeit von einer Minute ein. Dieser soll env | sort, pwd und id in eine Logdatei schreiben. So können Sie die tatsächliche Umgebung von cron prüfen, statt sie zu erraten.

Wie prüfe ich, ob cron meinen Job tatsächlich ausgeführt hat?

Lesen Sie das Log des Daemons. Verwenden Sie unter Debian und Ubuntu journalctl -u cron oder unter Fedora, Rocky und Alma journalctl -u crond. Bei manchen Images leitet rsyslog die Meldungen stattdessen in eine Datei unter /var/log weiter. Suchen Sie nach einem Eintrag in der Minute, die der Zeitplan angibt, und prüfen Sie, ob Ihr Befehl genannt wird. Fehlt der Eintrag, hatte cron den Zeitplan nie geladen. Prüfen Sie daher, ob Sie die richtige Crontab bearbeitet haben. Ein Eintrag ohne Ergebnis bedeutet, dass der Befehl gestartet und anschließend beendet wurde. Erfassen Sie seine Ausgabe mit einer Umleitung.

Warum funktioniert date +%Y in einer Crontab nicht?

cron behandelt % im Befehlsfeld speziell. Das erste nicht maskierte % beendet den Befehl. Alles danach wird diesem Befehl als Standardeingabe übergeben. Jedes weitere % wird zu einem Zeilenumbruch. Deshalb erreicht ein Dateiname mit Datumsformat das dafür vorgesehene Programm nicht. Maskieren Sie jedes Prozentzeichen als \%. Alternativ können Sie den Befehl in ein Skript verschieben und das Skript über cron aufrufen. Innerhalb eines Skripts hat das Prozentzeichen keine besondere Bedeutung.

Wohin wird die Ausgabe meines Cronjobs geschrieben?

An das lokale Mailsystem. Die Nachricht wird an den Besitzer der Crontab oder an den von MAILTO angegebenen Empfänger adressiert. Auf den meisten VPS-Images ist kein Mail Transfer Agent installiert. Deshalb wird die Nachricht verworfen, und der Job wirkt stillschweigend. Leiten Sie die Ausgabe mit >> /path/to/log 2>&1 in eine Datei um. Behalten Sie dabei diese Reihenfolge bei, damit die Standardfehlerausgabe der Standardausgabe folgt. Alternativ können Sie die Ausgabe durch logger -t myjob leiten und mit journalctl -t myjob wieder einlesen. Verwenden Sie > /dev/null 2>&1 nicht, solange Sie noch Fehler suchen.

Sollte ich cron oder einen systemd-Timer verwenden?

Verwenden Sie cron für einen einfachen Befehl zu einer festen Zeit. Das gilt besonders, wenn Sie den Job möglicherweise auf eine Maschine verschieben müssen, auf der systemd nicht läuft. Verwenden Sie einen Timer, wenn die Ausgabe ohne Umleitung im Journal erscheinen soll, wenn Sie einen abfragbaren Exit-Status benötigen oder wenn der Job erst nach dem Start des Netzwerks ausgeführt werden soll. Ein Timer bietet außerdem eine zufällige Startverzögerung und eine Richtlinie für Wiederholungen nach einem Fehler. Beide Varianten können auf demselben Server laufen. Sie können Jobs daher einzeln umstellen, sobald sich das lohnt.