☰

Warum führt mein Cronjob mein Shell-Skript nicht aus?

tag-icon • tag-icon linux shell-script cron
Warum führt mein Cronjob mein Shell-Skript nicht aus?

Ich habe eine Crontab, die jede Nacht einen Dump meiner Datenbank erstellt:

20 3 * * * /path/to/dailydump.sh

dailydump.shenthält:

#!/bin/sh

DATENAME=`date +%Y%m%d`

BASENAME="/path/to/dumps/db_${DATENAME}.sql"

/usr/bin/mysqldump -hhost -uusername -ppassword databasename > ${BASENAME}

Berechtigungen sind:

-rwx---r-x 1 ... dailydump.sh
drwxr-xrwx 2 ... dumps

Warum funktioniert mein Cronjob nicht?

Ich bin auf einem gemeinsam genutzten Server ohne Root-Zugriff. Es gibt keine Protokolle in /var/log/cronoder /var/log/syslog. Es gibt keine E-Mails in /var/mail/<user_name>oder /var/spool/mail/<user_name>(tatsächlich gibt es überhaupt nichts in /var/mail/und /var/spool/), [email protected]es werden keine Fehlermeldungen gesendet und 1 2 * * * /path/to/your/command &>/path/to/mycommand.logkeine Protokolldateien gespeichert. ps -ef | grep cron | grep -v grep?gibt nichts zurück. (Siehehttps://serverfault.com/a/449652)

Das gesamte Setup funktionierte einwandfrei, bis ich alle Dateien auf eine neue Domäne verschoben und eine neue Crontab einrichten musste. (Ja, ich habe alle Pfade und die Datenbankanmeldeinformationen aktualisiert. Ich habe das auch mehrmals überprüft.) Ich bin beim selben Hosting-Anbieter auf derselben Maschine, daher hat sich die Umgebung nicht geändert.

Für jede Hilfe wäre ich sehr dankbar.

"Lösung"

-auth=user:password -sourceOkay, das ist höchst seltsam. Im Hilfecenter meines Anbieters steht, dass ich vor dem Pfad zum Skript Folgendes hinzufügen muss, wenn sich das von einem Cronjob auszuführende Skript in einem passwortgeschützten Verzeichnis befindet . Also habe ich Folgendes hinzugefügt (mit der entsprechenden Authentifizierung):

20 3 * * * -auth=user:password -source /path/to/dailydump.sh

Das Ergebnis war, dasseine Fehlermeldung wurde mir per E-Mail zugeschickt( MAILTO=funktioniert also), und es wurden mir /bin/sh: -=: invalid optiondie verfügbaren Optionen mitgeteilt und aufgelistet. Das Beispiel im Hilfecenter hat eigentlich keinen physischen Pfad ( /path/to/file), sondern eine URL ( http://...) angegeben, also habe ich die Crontab gelöscht authund sourceerneut gespeichert undjetzt läuft der verdammte Cronjob!!„Die Crontab sieht Zeichen für Zeichen genauso aus wie vorher, aber jetzt läuft sie, ohne dass sich am Code etwas geändert hätte.“

Ich habe keine Ahnung, woran das lag, aber falschen Code einzufügen und ihn wieder zu löschen hat geholfen. o_O Es scheint, als ob der Cronjob tatsächlichtatlaufen die ganze Zeit (denn wenn es nicht läuft, wirft es offensichtlich einen Fehler), nur dass esTat nichts!Sehr mysteriös. Wenn mir das jemand (auf reproduzierbare Weise) erklären kann, biete ich eine Belohnung von 200 an und gewähre sie (nach der erforderlichen Wartezeit von zwei Tagen).

Außerdem hat mir @chaos eine andere Lösung vorgeschlagen, bei der das Shell-Skript vollständig vermieden wird und cron den Datenbank-Dump direkt durchführt (siehe die Kommentare zu seiner Antwort unten):

20 3 * * * /usr/bin/mysqldump -hhost -uusername -ppassword Datenbankname > /Pfad/zu/dumps/db_$(Datum +\%Y\%m\%d).sql

Vergessen Sie nur nicht, die Prozentzeichen zu escapen, sonst findet das Skript ein „unerwartetes EOF“.

Vielen Dank an alle für die Hilfe. Ich habe wieder viel gelernt (allerdings nicht, was hier falsch war).

Antwort1

Um sicherzustellen, dass der cronDaemon läuft und die erfüllt crontab, können Sie einen kleinen Test durchführen. Bearbeiten Sie Ihre crontabmit einem Eintrag wie diesem:

* * * * * /bin/date >>/tmp/test

Nach einer Minute schaue ich mir die Datei /tmp/test an. Wenn dort keine Datei vorhanden ist, läuft der Daemon höchstwahrscheinlich nicht. In diesem Fall würde ich mich an den Support des Anbieters wenden.

Bearbeiten:

Um die Umgebung in der Cron-Instanz zu bestimmen, müssen Sie Folgendes tun:

* * * * * /usr/bin/id >>/tmp/test
* * * * * /usr/bin/env >>/tmp/test

Sehen Sie sich jetzt den Inhalt der Datei an.

Antwort2

  1. Führen Sie das Skript direkt aus und prüfen Sie, ob es funktioniert.
  2. Je nachdem, wie Sie das Skript einrichten, sind einige Shell-Umgebungsvariablen möglicherweise nicht verfügbar, wenn das Skript unter Crontab ausgeführt wird.

Versuchen Sie, das Skript zu ändern, um zu testen, ob das Problem bei den Umgebungsvariablen liegt:

sh --login -c "/usr/bin/mysqldump -hhost -uusername -ppassword databasename > ${BASENAME} >  /path/to/LogFile.txt 2>&1"

verwandte Informationen