Warum läuft mein cron-Job nicht? 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 einen Ort gesendet, den Sie nicht prüfen. Fünf Ursachen erklären nahezu jede entsprechende Meldung: der Suchpfad, das Prozentzeichen, die falsche crontab-Datei, eine Ausgabe, die per E-Mail versendet wurde, 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 nicht Ihre .bashrc, ö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 Fakten.

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 Lösungsansatz. Beantworten Sie daher zuerst diese Frage.

Hat cron den Auftrag überhaupt ausgeführt?

Der Daemon hat in den verschiedenen Distributionsfamilien unterschiedliche 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 verschiedenen Logging-Konfigurationen unterscheidet. Sie prüfen nur zwei Dinge: Gibt es in der Minute, die Ihr Zeitplan vorgibt, einen Eintrag, und nennt dieser Eintrag Ihren Befehl? Ein Eintrag mit Ihrem Befehl bedeutet, dass cron seine Aufgabe erfüllt hat und der Fehler innerhalb des Befehls liegt. Fehlt ein Eintrag vollständig, hatte cron Ihren Zeitplan nicht geladen. Das ist Ursache 3 weiter unten.

Manche Images senden 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 nicht installiert. Minimale Cloud-Images und Container enthalten es 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 nichts davon 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 Sprachversionsmanager, eine virtuelle Python-Umgebung oder ein Go-Arbeitsbereich kommt als Ursache infrage. Der Job schlägt in der ersten Zeile fehl. Die Shell schreibt einen Fehler im Stil von "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 Rechner mit echo "$PATH". Entfernen Sie alle Einträge, die nur innerhalb einer interaktiven Sitzung vorhanden sind. Eine Regel ist hierbei wichtig: cron expandiert Variablen in diesen Zuweisungszeilen nicht. PATH=$PATH:/usr/local/bin speichert den Literaltext $PATH:/usr/local/bin. Dadurch enthält der Suchpfad des Jobs kein einziges 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 eine Shell-Funktion oder ein shims-Verzeichnis. Eine cron-Aufgabe 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. Sie ist auch der Grund, warum ein Dateiname mit Zeitstempel der klassische Fehler in einem Crontab-Eintrag ist.

Schreiben Sie 0 3 * * * /usr/bin/tar -czf /srv/backups/site-$(date +%F).tar.gz /srv/site, sieht tar niemals ein formatiertes Datum. cron schneidet die Zeile beim ersten % ab. Dadurch erhält die Shell eine unvollständige Befehlssubstitution, 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 anwendet, bevor irgendetwas gestartet wird. $(date +\%F) ist eine Befehlssubstitution, die später von der Shell angewendet wird, die cron startet. Entscheidend ist, zu wissen, welcher Ebene welches Zeichen gehört.

Die sicherere Vorgehensweise besteht darin, die Logik vollständig aus der Crontab herauszuhalten. Legen Sie sie in ein Skript. 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 Besitzern und unterschiedlicher Feldanzahl. Ein Auftrag in der falschen Datei bleibt unsichtbar.

• crontab -e bearbeitet die crontab des Benutzers, der den Befehl ausführt. sudo crontab -e bearbeitet die crontab von root. Zwei Personen, die dasselbe System untersuchen, lesen dadurch 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, das den Auftrag ausführen soll, tatsächlich installiert ist.
• /etc/crontab und jede Datei in /etc/cron.d enthalten zwischen Zeitplan und Befehl ein zusätzliches Feld: den Benutzer, unter dem der Auftrag ausgeführt wird. Wenn Sie eine fünfspaltige 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 namens backup.sh oder site.conf wird allein aufgrund 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 für die Gruppe oder andere Benutzer nicht 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 dieselbe Namensregel einhalten und außerdem das Ausführungsbit gesetzt haben. Ein fehlendes Ausführungsbit führt dazu, dass das Skript stillschweigend übersprungen wird.
• /etc/cron.allow und /etc/cron.deny legen fest, wer überhaupt eine crontab installieren darf. Wenn eine der beiden Dateien auf Ihrem System vorhanden ist, lesen Sie sie, bevor Sie davon ausgehen, dass Ihr Benutzer eine crontab verwenden darf.

Installieren Sie eine Benutzer-crontab mit dem Befehl crontab, statt die Spool-Datei von Hand zu bearbeiten. crontab prüft die Datei vor der Installation. 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 genauso aus, als würde cron Ihre Änderung ignorieren.

Der Besitzer bestimmt auch die Berechtigungen. Ein Auftrag in der crontab von root erstellt Dateien, in die die Anwendung, die diese Dateien liest, möglicherweise nicht schreiben kann. Ein Auftrag in der crontab eines normalen Benutzers kann ein nur für root zugängliches Verzeichnis nicht lesen. Wählen Sie den Besitzer passend zur Aufgabe: Die Wartung einer Anwendung gehört zum eigenen Konto der Anwendung. Das ist die Grundlage für WordPress wp-cron durch einen System-Cronjob ersetzen. Der Modus der von Ihrem Auftrag erstellten Dateien stammt aus der geerbten umask. Auch dieser Wert entspricht nicht der umask Ihrer Shell. Daher ist wie umask Dateiberechtigungen festlegt lesenswert, wenn die Ausgabe eines Auftrags nicht lesbar ist.

Ursache 4: Die Ausgabe ging an ein Postfach, das niemand liest

cron sammelt alles, was ein Job nach Standardausgabe und Standardfehler schreibt. Sobald der Job überhaupt etwas ausgibt, übergibt cron diesen Text an das lokale Mailsystem. Die Nachricht geht an den Besitzer der Crontab oder an die Adresse, die MAILTO angibt. Auf einem schlanken VPS ist normalerweise kein MTA (Mail Transfer Agent) installiert. Daher wird die Nachricht nicht zugestellt. Ihr 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 den Standardfehler an das Ziel weiter, auf das die Standardausgabe zu diesem Zeitpunkt zeigt. Deshalb muss diese Umleitung danach stehen. Bei der umgekehrten Reihenfolge, also 2>&1 >> file, behält der Standardfehler sein ursprüngliches Ziel. Der Fehler, nach dem Sie suchen, erreicht die Datei dann genau nicht.

Das Journal ist ein weiteres geeignetes Ziel. logger schreibt unter einem von Ihnen gewählten 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 neben den Cron-Einträgen. Der zeitliche Ablauf lässt sich so einfach nachvollziehen. Wenn Sie zusätzlich dokumentieren müssen, welche Person welchen Befehl auf dem Server ausgeführt hat, ist das ein separates System. Die Überwachung von Benutzerbefehlen auf Ihrem Server behandelt dieses Thema.

MAILTO="" am Anfang einer Crontab deaktiviert den Mailversand für die darunterstehenden Jobs. Das Setzen von MAILTO auf eine echte Adresse hilft nur, wenn ein funktionsfähiges MTA vorhanden ist. Prüfen Sie daher zuerst, ob Mails den Server verlassen, bevor Sie sich darauf verlassen.

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

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

Sobald der Befehl gefunden und seine Ausgabe erfasst wurde, bleibt alles andere, 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 verweist 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. Alternativ 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 das Verzeichnis. Ein relativer Pfad ist der häufigste einzelne Grund dafür, dass ein Auftrag „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 abweichende 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. Fügen Sie das vom Werkzeug angebotene nicht-interaktive Flag hinzu.
• 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 wegen Ihres geladenen Agenten funktioniert hat, nun bei der Authentifizierung fehl. Geben Sie dem Auftrag einen eigenen Schlüssel, der dem Benutzer des Auftrags gehört.
• Es gibt keinen Benutzer-Sitzungsbus. Daher schlägt systemctl --user aus einem cron-Auftrag 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 Grund. SELinux schränkt cron-Aufträge ein. Daher wird ein Auftrag, der auf einen Pfad mit einem unerwarteten Label zugreift, auch dann verweigert, wenn die Dateiberechtigungen korrekt aussehen. Prüfen Sie Verweigerungen mit sudo ausearch -m avc -ts recent und lesen Sie SELinux-Grundlagen für einen Server, bevor Sie etwas deaktivieren.

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

Raten Sie nicht länger, welche Umgebungsvariablen cron verwendet. Lesen Sie sie aus. Schreiben Sie ein Skript, das alle Variablen ausgibt, planen Sie es für jede Minute ein, warten Sie 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 Job 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. Lesen Sie anschließend /home/deploy/cron-probe.log aus und vergleichen Sie die Ausgabe mit denselben Befehlen, die Sie in Ihrer eigenen Shell ausführen. Die Zeile PATH, das Arbeitsverzeichnis und das Gebietsschema erklären den Fehler meist bereits. Beachten Sie zwei Details dieser Einrichtung: Die Prozentzeichen befinden sich im Skript, wo cron-Regeln nicht gelten, und der Pfad zur Protokolldatei ist für den Benutzer des Jobs beschreibbar.

Löschen Sie die Crontab-Zeile sofort, sobald Sie die Ursache gefunden haben. Ein Job, der jede Minute ausgeführt wird und an eine Datei anhängt, kann einen kleinen Datenträger füllen. Das geschieht zudem ohne sichtbare Meldung.

Ist der Zeitplan so gemeint?

Eine Zeile in der Benutzer-Crontab beginnt mit fünf Feldern: Minute, Stunde, Tag des Monats, Monat, Wochentag. Zwei dieser Felder interagieren auf eine Weise, die häufig überrascht.

Wenn der Tag des Monats und der 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. Wenn Sie einen bestimmten einzelnen Tag festlegen möchten, lassen Sie eines der beiden Felder auf * und prüfen Sie das andere im Script.

cron verwendet die Systemzeitzone. Viele VPS-Images sind auf UTC (koordinierte Weltzeit) eingestellt. Ein Job, den Sie für 03:00 geplant haben, läuft dann um 03:00 UTC. Das kann mitten in Ihrem Nachmittag sein. timedatectl zeigt an, welche Zeitzone Ihr System tatsächlich verwendet. 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 ausgeführt, sobald cron selbst startet. Das ist nicht zwangsläufig der Zeitpunkt, an dem das Netzwerk bereit ist. Ein Job, der DNS oder einen entfernten Host benötigt, kann daher beim Booten fehlschlagen und bei jedem anschließenden 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 Aufruf 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 kann eine Sache gut: einen Befehl zu einem bestimmten Zeitpunkt ausfü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 relativ zu network-online.target und unterstützt eine zufällige Verzögerung. Dadurch starten nicht hundert Server in derselben Sekunde. Wenn Ihr Job eine dieser Funktionen benötigt, ist ein systemd-Dienst und Timer auf einem VPS weniger Arbeit, als eine crontab-Zeile zu verteidigen. Auch das Verhalten bei Wiederholungen gehört dorthin, weil systemd-Neustartrichtlinien festlegen, was nach einem Fehler geschieht. cron hat darauf überhaupt keine Antwort.

Verwenden Sie cron weiterhin für kleine Jobs. Verschieben Sie alles mit Abhängigkeiten oder einer Wiederholungsrichtlinie in einen Timer. Beide Varianten 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?

Weil sich die Umgebung Ihrer Shell von der Umgebung von cron unterscheidet. Ihre Login-Shell liest /etc/profile und ~/.bashrc ein. Diese setzen PATH, das 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 ein, der einmal pro Minute läuft und env | sort, pwd und id in eine Logdatei schreibt. 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 für die Minute, die in Ihrem Zeitplan angegeben ist, und prüfen Sie, ob Ihr Befehl genannt wird. Gibt es keinen Eintrag, hatte cron den Zeitplan nicht geladen. Prüfen Sie daher, ob Sie die richtige Crontab bearbeitet haben. Ein Eintrag ohne Ergebnis bedeutet, dass der Befehl gestartet wurde und anschließend beendet wurde. Leiten Sie seine Ausgabe mit einer Umleitung in eine Datei um.

Warum funktioniert date +%Y in einer Crontab nicht?

cron behandelt % im Befehlsfeld als Sonderzeichen. Das erste nicht maskierte % beendet den Befehl. Alles danach wird diesem Befehl als Standardeingabe übergeben. Jedes weitere % wird zu einem Zeilenumbruch. Daher erreicht ein Dateiname mit Datumsformat nicht das dafür vorgesehene Programm. 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 Mail-System, adressiert an den Eigentümer der Crontab oder an das, was MAILTO angibt. Auf den meisten VPS-Images ist kein Mail Transfer Agent installiert. Daher wird die Nachricht verworfen und der Job wirkt, als wäre er ohne Ausgabe beendet worden. 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 auslesen. 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 Uhrzeit. Das gilt besonders, wenn Sie den Job möglicherweise auf eine Maschine verschieben müssen, auf der systemd nicht ausgeführt wird. Verwenden Sie einen Timer, wenn die Ausgabe ohne Umleitung im Journal erscheinen soll, wenn Sie den Exit-Status abfragen möchten, eine Ausführung nach dem Start des Netzwerks benötigen, eine zufällige Startverzögerung festlegen möchten oder nach einem Fehler eine Wiederholungsrichtlinie benötigen. Beide Varianten können auf demselben Server ausgeführt werden. Sie können die Jobs daher einzeln umstellen, sobald sich der Aufwand dafür lohnt.