Cron-Job wird nicht ausgeführt?

Ich habe alle 5 Minuten einen Cron-Job erstellt, um meine Minecraft-Welt aus meinem RAM zu retten.
Ich habe das Skript getestet und es scheint zu funktionieren.

So sieht das Skript aus:

#!/bin/sh


VOLATILE="/home/jonathan/Games/Minecraft/Server/world/"
PERMANENT="/home/jonathan/Games/Minecraft/Server/world_storage/"
rsync -r -t -v "$VOLATILE" "$PERMANENT"

Also habe ich einen Cron-Job hinzugefügt, um das Skript alle 5 Minuten auszuführen, und es scheint nicht ausgeführt zu werden.

Dies ist das Skript, das ich verwendet habe:

*/5 * * * * bash /home/jonathan/Games/Minecraft/Server/Backup.sh

Kann mir bitte jemand helfen?

Akzeptierte Antwort:

Sie haben nicht angegeben, wie Sie Ihren Cronjob hinzugefügt haben. Das macht einen großen Unterschied:wenn Sie crontab -e verwendet haben Innerhalb Ihres eigenen Kontos werden Skripte mit Ihrem Benutzer ausgeführt (und daher hat der crontab-Eintrag ein Feld weniger – den Benutzer, der ihn ausführt, wie das bekannt ist). Wenn Sie Ihr obiges Snippet einfach nach /etc/cron.d kopiert haben , würde es fehlschlagen, da Sie keinen Benutzer angegeben haben (oder besser gesagt, weil es keinen Benutzer namens „bash“ findet). Gehen Sie also folgendermaßen vor:

1. Aktualisieren Sie Ihre Frage mit Informationen darüber, wie Sie den Cronjob hinzugefügt haben
2. Überprüfen Sie die Systemprotokolle (/var/log/syslog; sie könnten auf mögliche Fehler hinweisen)
3. fügen Sie einige Debug-Ausgaben zu Ihrer Backup.sh hinzu Skript, um zu sehen, ob es gestartet ist

Der dritte Punkt kann auf mehrere Arten erreicht werden:

• fügen Sie ein >>/tmp/testlog.log hinzu am Ende Ihres Crontab-Eintrags (um die Ausgabe in eine Datei umzuleiten, die Sie untersuchen können; zusätzlich ein 2>&1 würde die Ausgabe der Fehlerkonsole enthalten)
• fügen Sie einige Zeilen zu Ihrem Skript selbst hinzu, wie z.B. echo "Backup.sh started">/tmp/testlog.log

Außerdem:Wie Sie beabsichtigen, Ihr Skript mit bash auszuführen , sollten Sie es nicht anweisen, /bin/sh zu verwenden (was dazu führen würde, dass dash verwendet wird bei einer standardmäßigen Ubuntu-Installation), sondern /bin/bash . Machen Sie es dann ausführbar, und Sie können sogar das „bash“ in Ihrem Crontab-Eintrag weglassen.

Aktualisierung:

Laut Ihrem Kommentar zu meiner Antwort haben Sie crontab -e verwendet um den Job zu erstellen, und laut Ihren Systemprotokollen wird er ausgeführt, aber die Definition ist eher

*/5 * * * * bash /home/jonathan/Games/Minecraft/Server/Backup.sh &>/dev/null

Dadurch wird die gesamte Ausgabe auf den größten Speicher in Ihrem System umgeleitet, das „schwarze Loch“:/dev/null isst alles (gibt aber nie etwas zurück). Wenn Sie sowohl STDOUT als auch STDERR auf diese Weise umleiten, werden Ihnen keine Fehlermeldungen mehr angezeigt – Sie wissen also nie, dass sie überhaupt aufgetreten sind, geschweige denn die Details. Zum Testen sollten Sie &>/dev/null weglassen Teil komplett. Auch wenn es funktioniert, sollten Sie nur unnötige Ausgaben unterdrücken – sonst wissen Sie nie, wenn etwas schief geht. Lassen Sie also zumindest das kaufmännische Und weg, damit Cron auftretende Fehler melden kann.

Verwandte:USB-Dock für 4 TB Seagate HDD funktioniert nur mit weniger als 2,2 TB Daten?

Außerdem:Sobald die Ausgabe umgeleitet wird (wie in Ihrem Fall nach /dev/null ), führt das Anhängen einer weiteren Weiterleitung an das Ende zu keinen Ergebnissen, da bereits alles weg ist. Also muss ich den obigen Rat von „Hinzufügen … am Ende Ihres Crontab-Eintrags“ zu „Ersetzen Sie das in Ihrem Crontab-Eintrag“ anpassen 😉