Crontab-Befehl wird nicht ausgeführt

673
Irvin Denzel Torcuato

Ich habe einen Befehl in meiner crontab, der nicht korrekt ausgeführt wird. Dies sollte die Datenbank jeden Tag zur angegebenen Zeit sichern. Ich habe versucht, den Befehl in meinem Terminal auszuführen und funktioniert ordnungsgemäß.

Um meine Crontab zu bearbeiten, verwende ich crontab -edie aktuelle Cron-Registerkarte, die Folgendes enthält:

# Save online agent status every 2 minutes */2 * * * * /usr/bin/python /home/dummy/scm/qt-savu/userstatus.py >> /home/dummy/qt-savu/userstatus.log  # Save Hourly call counts every XX:59 59 * * * * /usr/bin/python /home/dummy/scm/qt-savu/hourlylog.py >> /home/dummy/qt-savu/hourlycc.log  # Backup albatross everyday 58 5 * * * /usr/bin/mysqldump -udummy -ppassword albatross | /bin/gzip > /home/dummy/Documents/backups/`/bin/date +%y.%m%d`.albatross.tar.gz  # Backup bert everyday 58 5 * * * /usr/bin/mysqldump -udummy -ppassword bert | /bin/gzip > /home/dummy/Documents/backups/`/bin/date +%y.%m%d`.bert.tar.gz

Andere Befehle in der Crontab funktionieren ordnungsgemäß. Die folgenden Befehle funktionieren nicht:

# Backup albatross everyday 58 5 * * * /usr/bin/mysqldump -udummy -ppassword albatross | /bin/gzip > /home/dummy/Documents/backups/`/bin/date +%y.%m%d`.albatross.tar.gz  # Backup bert everyday 58 5 * * * /usr/bin/mysqldump -udummy -ppassword bert | /bin/gzip > /home/dummy/Documents/backups/`/bin/date +%y.%m%d`.bert.tar.gz

Die Protokollausgabe sieht folgendermaßen aus

Sep 4 05:56:01 luna CRON[18815]: (dummy) CMD (/usr/bin/mysqldump -udummy -ppassword bert | /bin/gzip > /home/dummy/Documents/backups/`/bin/date '+) Sep 4 05:56:01 luna CRON[18812]: (CRON) info (No MTA installed, discarding output) Sep 4 05:56:01 luna CRON[18817]: (dummy) CMD (/usr/bin/mysqldump -udummy -ppassword albatross | /bin/gzip > /home/dummy/Documents/backups/`/bin/date '+) Sep 4 05:56:01 luna CRON[18813]: (CRON) info (No MTA installed, discarding output)

Wie ich beobachtete, stoppt die Ausgabe des Protokolls um /bin/date.

2
Ich würde empfehlen, dass Sie Ihre Befehle in ein Shell-Skript schreiben und diese dann aufrufen, damit die Crontab einfach zu lesen ist albal vor 8 Jahren 1
danke für den tipp, erhöht das nicht die komplexität? Irvin Denzel Torcuato vor 8 Jahren 0
Nein, es erhöht nicht die Komplexität. Es vereinfacht tatsächlich das Management, wenn Sie mich fragen. Auf diese Weise verwaltet crontab simple, wann Aufgaben ausgeführt werden, und die Aufgaben in den Shell-Skripts können so einfach oder komplex sein, wie es nötig ist. Das Problem beim Hinzufügen von Inline-Befehlen in der crontab ist manchmal Syntaxprobleme, die durch das Zusammendrücken von Einzeilen in dieses Format verursacht werden. JakeGould vor 8 Jahren 0

1 Antwort auf die Frage

4
alienth

%wird speziell von cron behandelt. Es wird verwendet, um das Ende des Befehlsteils und den Beginn der Standardeingabe zu kennzeichnen. Als solche müssen Sie es entkommen, etwa so: \%.

Von der Crontab-Manpage:

Der gesamte Befehlsteil der Zeile bis zu einem Zeilenvorschub oder% -Zeichen wird von / bin / sh oder von der in der SHELL-Variablen der Crontab-Datei angegebenen Shell ausgeführt.

Gott hat gesandt, ist seit mehr als einer Stunde davon beunruhigt ... Gibt es eine Liste mit Sonderzeichen in den Manpages? Das erklärt die seltsame Syntaxhervorhebung - (Bearbeiten) Irvin Denzel Torcuato vor 8 Jahren 0
In der Manpage ("man 5 crontab") hat das sechste Feld nur diesen einen Sonderzeichen. alienth vor 8 Jahren 0
@IrvinDenzelTorcuato Auch - wie in den Kommentaren zu Ihrer ersten Frage erläutert - wird aus diesem Grund dringend empfohlen, dass Sie die Crontab-Einträge einfach ein Skript aufrufen und dann die gesamte Kernlogik in einem eigenständigen Skript sichern. In diesem Fall bin ich ziemlich sicher, dass das Problem mit einem eigenständigen Skript gelöst werden würde. Nicht zu sagen, dass diese Antwort falsch ist - sie ist richtig -, zeigt aber auch die Fallstricke bei der Erstellung von Shell-Script-Einzeilen in Crontab-Befehlen. JakeGould vor 8 Jahren 0

Verwandte Probleme