Cronjob erstellen

  • Cioa zusammen.


    Ich möchte auf meinem QNAP NAS TS-253E einen cronjob erstellen.


    Ich bin 100pro Windows lastig und arbeite mich in das QTS ein. QTS 5.0.1.2376

    Auf dem Win10 habe ich PuTTy installiert und kann auch auf das NAS zugreifen.


    Wie kann ich einen cronjob programmieren?


    Kann mir da jemand unter die Arme greifen und bei einer Schritt für Schritt Anleitung für dummies helfen?


    8|

  • Als Grundbasis ist mein alter Beitrag:



    Ich bin seit drei Wochen mit dem Support daran für eine Lösungsfindung.

    Kompliment an den Support. der Support ist wirklich bemüht mit mir das Problem zu lösen.

    Wir konnten das Problem lokalisieren und eingrenzen. Leider gibt es noch keine Schnelle Lösung.

    Vermutlich ein Fehler in der HSB3 Software.

    Es bringt nichts, den ganzen schriftlichen Verkehr mit dem Support hier wieder zu geben.

    Der Vorschlag vom Support um das Problem temporär zu lösen, ist ein Cronjob zu erstellen.


    Das ist die Momentane Situation.


    Anstelle HBS 3 muss ich einen cronjob erstellen.

    Anstelle des HBS 3 soll der cronjob die Synchronisation auf die Ext USB HDD übernehmen.


    Also, von da an ist bei mir Blackout.

  • Hier kannst Du auch noch was zum Thema cron finden (in der .PDF).


    Gruss

  • Hast Du die aktuelle Version von HBS 3 Hybrid Backup Sync 21.2.0508 schon installiert.

  • Guten Morgen1


    Ich versuche auch gerade einen Cronjob zu erstellen und scheitere leider kläglich.


    Ich würde gerne zwei rsync Kommandos jeden Tag um 23:00 ausführen lassen


    rsync -av --delete /share/CACHEDEV1_DATA/.system/data.m10 /share/Backups/QuMagie/

    rsync -av --delete /share/CACHEDEV1_DATA/.system/facedata /share/Backups/QuMagie/


    Wenn ich die Kommandos per SSH ausführe, funktioniert alles (als admin user).


    Die Einträge in crontab habe ich laut QNAP Wiki mit vi erstellt und nicht per "crontab -e"

    vi /etc/config/crontab


    Und diese beiden Zeilen habe ich eingetragen:

    Code
    0 23 * * * rsync -av --delete /share/CACHEDEV1_DATA/.system/data.m10 /share/Backups/QuMagie/
    0 23 * * * rsync -av --delete /share/CACHEDEV1_DATA/.system/facedata /share/Backups/QuMagie/

    Zu guter Letzte dann crontab neu starten:

    crontab /etc/config/crontab && /etc/init.d/crond.sh restart


    Leider führt er die Kommandos aber nicht aus. Woran kann das liegen?


    Danke.

  • Am besten den kompletten Pfad zu rsync angeben.


    Gruss

  • Hallo,


    Ich habe jetzt /usr/bin/rsync .... probiert. Hat aber leider auch nicht das gewünscht Ergebnis gebracht. Direkt in der Shell funktioniert der absolute Pfad und rsync läuft korrekt durch. :(

  • Gibt es Einträge in ein irgendeinem Log?

    Zur Not einen anderen Befehl eintragen (z.b. touch test.txt und kontrollieren, ob der Job als solches ausgeführt wird.

    Wenn Dein Job als "admin" funktioniert, dann kann man daraus keine Rückschlüsse auf cron schliessen.

    Als Benutzer hast Du andere Umgebungsvariablen.


    Gruss

  • Häng an deinen rsync-Befehl Folgendes an:

    Code
    rsync ... >/share/Freigabe/logdatei 2>&1

    (Freigabe muss durch den Namen einer existierenden Freigabe ersetzt werden.)


    Morgen früh kannst du dann sehen, ob Cron den Eintrag zu starten versucht hat und welcher Fehler aufgetreten ist.

  • Code
    25 17 * * * /usr/bin/rsync -av --delete /share/CACHEDEV1_DATA/.system/data.m10 /share/Backups/QuMagie/ > /share/Backups/QuMagie/logdatei 2>&1
    25 17 * * * /usr/bin/rsync -av --delete /share/CACHEDEV1_DATA/.system/facedata /share/Backups/QuMagie/ > /share/Backups/QuMagie/logdatei_2 2>&1

    Ich habe jetzt folgende Zeilen drinnen gehabt, sollte also schon ausgeführt worden sein. Leider sind keine Dateien erstellt worden. Es wirkt so als ob das rsync Kommando gar nicht ausgeführt wird?


    Gibt es Einträge in ein irgendeinem Log?

    Gute Frage ... Aktuell bin ich noch auf der Suche nach den Log Files. Unter /mnt/HDA_ROOT/.logs bin ich nicht fündig geworden

  • Es wirkt so als ob das rsync Kommando gar nicht ausgeführt wird?

    Das sieht so aus. Selbst wenn rsync ohne Ausgabe gelaufen wäre, hätte eine leere Logdatei angelegt werden müssen. Edit: Siehe unten.


    Gib mal

    Code
    sudo crontab -l

    ein, ob der laufende Cron dein rsync-Kommando überhaupt in der Liste hat.


    EDIT:

    Halt! Stopp! Ich sehe gerade, du machst da ziemlichen Murks mit den rsync-Jobs. Du schreibst von zwei Jobs in dasselbe Zielverzeichnis mit der Option --delete, und deine Log-Dateien werden auch dort angelegt. Diese Option --delete bewirkt, dass Dateien, die im Quellverzeichnis nicht vorhanden sind, im Zielverzeichnis gelöscht werden.

    Das heißt

    • Der erste Job löscht alle vom zweiten Job angelegten Dateien, da es die in seinem Quellverzeichnis nicht gibt.
    • Der zweite Job löscht alle vom ersten Job angelegten Dateien, da es die in seinem Quellverzeichnis nicht gibt.
    • Beide Jobs löschen die gerade angelegten Logdateien wieder, weil es die im Quellverzeichnis nicht gibt.

    => Bitte zwei verschiedene Zielverzeichisse verwenden und die Logdateien in einem dritten Verzeichnis anlegen.

    Einmal editiert, zuletzt von Anthracite ()

  • Stimmt. Das ist natürlich ein Denkfehler gewesen :(


    Ich habe die Zeilen jetzt so geändert. Diese kommen auch bei sudo crontab -l retour. Sind also drinnen.

    Code
    0 10 * * * /usr/bin/rsync -av --delete /share/CACHEDEV1_DATA/.system/data.m10 /share/Backups/QuMagie/db > /share/Backups/QuMagie/logs/logdatei 2>&1
    
    0 10 * * * /usr/bin/rsync -av --delete /share/CACHEDEV1_DATA/.system/facedata /share/Backups/QuMagie/faces > /share/Backups/QuMagie/logs/logdatei_2 2>&1

    Kopiert wurde allerdings wieder nichts um 10:00 auch keine Log Files angelegt. :(


    PS: ich habe natürlich auch mit crontab /etc/config/crontab && /etc/init.d/crond.sh restart neugestartet.

  • Jetzt habe ich mal deinen rsync-Befehl bei mir im Cron eingefügt. Ergebnis:

    • Die Log-Datei wird immer erzeugt, egal ob rsync was getan hat oder nicht. So sollte es bei dem Parameter -v, den du benutzt hast, auch sein, da damit eine erweiterte Ausgabe (mit Statistiken) geschrieben wird.
    • Mit den von dir gegebenen Pfaden hat es nicht funktioniert, da bei mit .system unter /share/CE_CACHEDEV1_DATA (man beachte "CE_") liegt. Aber auch mit falschen Pfad wird die Logdatei geschrieben.

    Funktioniert denn der Befehl, wenn du ihn direkt startest (also nicht über Cron)? Wird dabei die Logdatei geschrieben?


    Wenn das geht, dann teste mal deine Crontab mit etwas ganz simplem wie

    Code
    echo "Hallo Welt" > /share/Backups/QuMagie/logs/echo-datei

    Wird dann die Datei geschrieben?


    Wenn nein, werden denn anderen Befehle aus der Crontab ausgeführt?

    Hast du vllt. weiter vorne in der Crontab einen fatalen Syntaxfehler? (Hatte ich noch nie, aber bei mir funktioniert es ja auch.)

  • Ja, das Kommando direkt in der Shell ausgeführt, funktioniert. Bei mir ist der Pfad auch nicht mit CE_ vorne. Der Order wurden synchronisiert und auch das Log geschrieben.


    Über den Cronjob allerdings (nach wie vor) nicht. Ich habe in der Zwischenzeit das letzte Software Update von QNAP installiert. Hat nichts geändert.


    Der "Hallo Welt" Befehl wird leider auch nicht ausgeführt.


    Ich habe bisher nie einen Befehl in crontab eingefügt. Alles was dort drinnen ist, kommt vom System direkt. Seit ich mit rsync begonnen habe, wurden auch durch das System neue Einträge gemacht. Daher glaube ich ehrlich gesagt nicht, dass es einen Syntax Fehler gibt. :(


    Wenn nein, werden denn anderen Befehle aus der Crontab ausgeführt?

    Hast du vllt. weiter vorne in der Crontab einen fatalen Syntaxfehler? (Hatte ich noch nie, aber bei mir funktioniert es ja auch.)

    Es dürfte doch daran gelegen haben. Ich hab mir jetzt die crontab Datei auf den Desktop geholt und dort bearbeitet. Dabei habe ich gesehen, dass am Anfang etliche Kommandos ca. 25x drinnen waren. Diese habe ich gelöscht und meine Kommandos ganz an den Anfang der Datei geschrieben.


    Siehe da, diese wurden ausgeführt.


    Jetzt wäre natürlich interessant herauszufinden ob die Duplikate das Problem waren, oder ob es ein Befehl weiter unten in crontab ist.

    Einmal editiert, zuletzt von maehmann () aus folgendem Grund: Ein Beitrag von maehmann mit diesem Beitrag zusammengefügt.