Täglicher Cron-Job läuft nicht

10

Ein kurzer Überblick: Ich habe ein Skript, das mein Quellcode-Repository täglich von SVN in einem Tarball für diesen Tag sichert. Ich habe das Skript getestet und es funktioniert sehr gut, solange ich es als sudo ausführe, da es das Ausgabeverzeichnis besitzt.

Das Problem ist also, dass ich dies täglich ausführen möchte, also habe ich einen Link dazu in das Verzeichnis /etc/cron.daily eingefügt. Hier ist der Inhalt des Verzeichnisses.

thom@spenser:/etc/cron.daily$ ls -l
total 60
-rwxr-xr-x 1 root root   189 2011-09-14 02:21 apport
-rwxr-xr-x 1 root root 15535 2011-10-06 11:30 apt
-rwxr-xr-x 1 root root   314 2011-08-08 16:57 aptitude
lrwxrwxrwx 1 root root    24 2012-02-28 11:05 backup -> /usr/local/bin/backup.sh
-rwxr-xr-x 1 root root   502 2011-06-08 11:48 bsdmainutils
-rwxr-xr-x 1 root root   256 2011-10-06 04:04 dpkg
-rwxr-xr-x 1 root root   372 2011-10-04 16:50 logrotate
-rwxr-xr-x 1 root root  1353 2011-07-27 07:17 man-db
-rwxr-xr-x 1 root root   606 2011-08-17 09:16 mlocate
-rwxr-xr-x 1 root root   249 2011-06-24 05:36 passwd
-rwxr-xr-x 1 root root  2417 2011-07-01 17:25 popularity-contest
-rwxr-xr-x 1 root root   383 2011-09-30 15:09 samba
-rwxr-xr-x 1 root root  3594 2011-09-19 20:07 standard
thom@spenser:/etc/cron.daily$

Das Problem ist, dass es einfach nie läuft. Hier sind die Berechtigungen für dieses Skript:

thom@spenser:/etc/cron.daily$ ls -l /usr/local/bin/backup.sh 
-rwxr-xr-x 1 root root 260 2012-02-28 11:03 /usr/local/bin/backup.sh

Ideen?

bash cron

— Thom
quelle

2

Wenn möglich, schließen Sie einige Ihrer anderen offenen Fragen, indem Sie die beste Antwort auswählen (falls vorhanden). Wir brauchen Benutzer, die ihre Fragen pflegen, damit die Website ein effektives Werkzeug für die nächste Person mit Ihren Problemen sein kann. Weitere Informationen zu Best Practices finden Sie in den FAQ zum Stellen von Fragen .

— Bruno Pereira

37

Versuchte dies

run-parts --test /etc/cron.daily

Es wurde festgestellt, dass meine Datei update.ubuntu nicht angezeigt wurde. Auch bemerkt, dass meine Datei eine Erweiterung hatte (hat Punkt darin).

Schritte, um dies zu beheben.

Mein update.ubuntu wurde in update-ubuntu umbenannt
Jetzt wieder run-parts --test /etc/cron.daily, diesmal kam meine Datei!

— D Durga Prasad
quelle

1

Ja, das hat es für mich behoben. Es mag keine Punkte im Dateinamen, das Umbenennen meiner Datei von myscript.sh in myscript hat für mich funktioniert.

— Matt Parkins

3

Dies muss höher sein. Ich hatte mein Skript als die traditionelle "backup.sh" gespeichert. Das Entfernen des Teils ".sh" hat das Problem behoben. Danke vielmals!

— David

Vielen Dank! Der Typ, der sich entschlossen hat, .sh-Dateien implizit aus dem täglichen Cron zu entfernen, sollte beschämt werden!

— Sylvain

Sollte öffentlich ausgepeitscht werden! ;-) Ich frage mich, wie viel Zeit die Menschen durch diese Entscheidung gemeinsam verloren haben ... Ich frage mich auch, ob es einen guten Grund dafür gab?

— Xastor

3

Könnte eines von mehreren Dingen sein:

Wurzelpfad:

Abhängig von den ausgeführten Befehlen müssen Sie möglicherweise die PATH-Variable des Root-Benutzers erweitern, indem Sie die folgende Zeile oben in die crontab-Datei einfügen:

PATH = / usr / sbin: / usr / bin: / sbin: / bin

src: https://help.ubuntu.com/community/CronHowto

Oder verwenden Sie einfach vollständige Pfade zu jedem Befehl in Ihrem Skript: /bin/lsstatt lszum Beispiel. ( which lsan der Kommandozeile für Pfade).

Es gibt einen seltsamen Fehler bei Punkten im hier angegebenen Dateinamen . Kann sich auf die Datei erstrecken, auf die Sie verlinken, obwohl dies unwahrscheinlich erscheint.

Speichern Sie die Ausgabe aus der Sicherungsdatei? Setzen Sie so etwas in die erste Zeile, um festzustellen, ob es überhaupt nicht läuft oder läuft, aber irgendwann fehlschlägt.

/bin/echo "Attempting to run backup" >> /path-to-home/backup.log

Versuchen Sie alternativ, das Skript direkt zur crontab-Datei hinzuzufügen:

sudo -i
crontab -e
[add the next line to the file, then save and exit]
33 15 * * * /usr/local/bin/backup.sh

läuft jeden Tag um 15:30 Uhr, wenn die Maschine eingeschaltet ist. Verwenden Sie * * * * * während des Tests, um einmal pro Minute zu laufen, bis Sie es zum Laufen bringen.

— Sean
quelle

1

Von der Verwendung absoluter Pfade in Skripten wird abgeraten. Wenn Sie nicht wissen, was PATH ist, legen Sie es selbst im Skript fest. Siehe Gründe, warum Crontab nicht funktioniert

— Geirha

Nützlicher Link, danke. Der angegebene Grund, keine vollständigen Pfade zu verwenden, ist die Portabilität. Meinetwegen. Eine andere sinnvolle Lösung besteht darin, die Befehle, die Sie zu Beginn des Skripts verwenden, zusammen mit anderen Konfigurationen zu definieren: LS = / bin / ls; SRC_DIR = / home / joe / src. Verwenden Sie dann $ LS $ SRC_DIR. Hält alles oben und an einem Ort definiert.

— Sean

Ich finde das, um die Lesbarkeit zu verringern, und Sie müssen jeden BEFEHL = / path / to / Befehl für jedes neue System durchgehen, auf dem es ausgeführt werden soll. Auf einem System können sich alle benötigten Befehle in / usr / bin befinden, auf einem anderen befinden sich einige in / bin, andere in / usr / bin. Wenn Sie sowohl / usr / bin als auch / bin in PATH haben, ist dies kein Problem. Nebenbei bemerkt sollten Variablennamen in Kleinbuchstaben geschrieben werden, da Sie sonst das Risiko eingehen, spezielle Shell-Variablen oder Umgebungsvariablen zu überschreiben.

— Geirha

re: Variablennamen in Großbuchstaben. Ich habe das immer ohne viel Nachdenken getan, aufgrund der ersten Skripte, die ich dabei gesehen habe. Aber Sie haben Recht, es gibt keinen Vorteil und keine Chance auf einen Nachteil. Vielen Dank, dass Sie darauf hingewiesen haben und diese Gewohnheit jetzt brechen.

— Sean

1

Suchen Sie in Ihrem Syslog nach Nachrichten wie:

crond: (*system*) BAD FILE MODE

Die Dateien müssen auf 644 beschränkt sein (ist ausreichend):

chmod 0644 /etc/cron.d/my_crontab

— Tom H.
quelle