gzip via cronjob erzeugt leere Dateien - kein Fehler bei manueller Ausführung

  • Hallo zusammen,


    ich möchte einmal täglich per Cronjob ("geplante Aufgaben") ein Datenbank-Backup erstellen. Ich führe dazu die folgenden Befehl aus:


    mysqldump -ukxxx_root -pxxx -h10.35.46.104 dbname | gzip > /Backups/db_backup_$(date '+\%Y-\%m-\%d').sql.gz


    Dieser Befehl, per Cronjob ausgeführt, führt allerdings im Backup-Folder zu leeren Dateien.


    Derselbe Befehl führt aber zu einem ordnungsgemäßen Backup in allen folgenden Fällen:

    a) Ausführung per Kommandozeile

    b) Ausführung per "Jetzt ausführen"-Button im WCP

    c) wenn ich den gzip-Befehl weglasse und die Datei als .sql-Datei abspeichere (funktioniert dann auch per Cronjob-Ausführung).


    Error-Log ist leer und Datei ist auch leer. Woran kann das liegen? Irgendwelche fehlenden Schreibrechte von gzip bei Ausführung über den Cronjob?

  • Noch interessanter ein Trick, den ich aus stackoverflow übernommen habe: Mysqldump und gzip nacheinander ausführen:


    mysqldump -ukxxx_root -pxxx -h10.35.46.104 dbname > /Backups/db_backup_$(date '+\%Y-\%m-\%d').sql && gzip /Backups/db_backup_$(date '+\%Y-\%m-\%d').sql


    Dies führt zum gewünschten Ergebnis, auch per Cronjob-Aufruf. Für mich an diesem Punkt also durchaus auch eine permanente Lösung. Bliebe die Frage, wieso die Output-Übergabe aus mysqldump an gzip in einem Schritt per Cronjob nicht funktioniert, per Kommandozeile aber schon?

  • ThomasChr Nein?


    gzip bekommt die Daten (ohne Argumente) als STDIN und gibt sie als STDOUT aus. Müsste doch passen? Oder habe ich da einen Denkfehler?

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Als ich ein Skript zum Monitoring von Websites per Cron gebaut habe, ist mir das Problem im Webhosting auch aufgefallen. Es wollte mir einfach nicht gelingen, irgendwas auf den STDOUT auszugben und den dann in eine Datei umzuleiten. Beim Testen auf der Seite, wo man den Cronjob definiert, hatte es noch funktioniert. Im Cronjob selbst dann nicht mehr, alles leer. Mein PHP-Skript zum Seitenabruf mit cURL wurde definitiv ausgeführt, ich habe die Zugriffe in den Serverlogs gefunden. Aber die nach STDOUT ausgegebenen Ergebnisse (TTFB usw) kamen nicht in meiner Datei an, in der ich sie sammeln wollte. Sie wurde noch nicht mal angelegt. Letztlich habe ich auf ein Forschungsprojekt verzichtet und alles direkt aus dem PHP-Skript in die Datei geschrieben. Das hat natürlich sofort problemlos funktioniert.

  • Befehl nicht gefunden | Befehl nicht gefunden > Leere Datei


    Meistens ist es sowas in der Art, weil im Cron der PATH nicht so gesetzt ist wie auf der vollwertigen Shell.


    Aber klar, dann dürfte die Variante mit && eigentlich auch nicht funktionieren. Vielleicht doch ein Schreibfehler gehabt?


    Es ist ein Ratespiel, du musst für jeden Befehl in der Kette auch stderr und den Exitcode mit einfangen um da weiterzukommen.

  • Nein, kein Schreibfehler, es bleibt reproduzierbar. Ich tippe, es handelt sich um einen Konfigurationsfehler seitens netcup, ggf direkt in gzip, da sich meine Erfahrungen ja mit denen von tab decken. Ein Schreibfehler fällt für meine Begriffe auch deshalb aus, weil sich der unveränderte Befehl ja sowol über den Button "Befehl ausführen" als auch über die Shell ausführen lässt und zum erwarteten Ergebnis führt.


    Wie kann ich stderr abfangen? Wenn ich ihn in eine Datei schreiben möchte, ist auch diese leer, und die E-Mail, die ich im WCP für den Fehlerfall definieren kann, wird anscheinend auch nicht versendet.

  • STDERR umleiten: 2> /path/to/file


    STDERR und STDOUT umleiten: &> /path/to/file


    Wie führst Du diese Befehle überhaupt aus? Stehen die in einem eigenen Script inkl. Shebang (z.B. /bin/bash) oder tippst Du die direkt ein? Letzteres könnte die Probleme als Cronjob nämlich durchaus erklären.


    Bei einem Bashscript könntest Du nach der Shebang auch mal so etwas einfügen, das zeigt gerne mal Fehler auf, die man sonst übersieht: set -euf -o pipefail

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)