crontab ist nicht persistent

    Hallo zusammen,


    ich verwende den lokalen QTS crontab für diverse Container Backup Scripts. Das hat auch alles schon mal funktioniert. Aber irgendwie wurde das wohl mal mit nem Systemupdate "ausgebaut".

    Das Lustige ist, meine crontab Zeilen sind schon noch da. Aber erst nachdem ich den crontab reloade (also so wie man es macht, wenn man was verändert hat) greifen meine Einstellungen wieder.

    Mir scheint nach jedem Reboot lädt der crond nur seine QTS default Jobs. Nach nem Reload vom crond (ohne zuvor etwas erneut zu verändern) gehen dann auch meine Jobs.

    ich weiß, dass crontab -e nicht funktioniert auf QTS.

    Mache es seit jeher schon wie hier beschrieben -> https://wiki.qnap.com/wiki/Add_items_to_crontab


    Hat wer ne Idee, was hier falsch läuft? mein QTS ist auf latest Stand.

    Zitat von blue_focus

    ...mein QTS ist auf latest Stand.

    Ich liebe solche Angaben! :rolleyes: Was heißt das? Erwartest Du nun, das man jede FW für jedes Modell auswendig kennt?

    Außerdem ist nächsten Monat/nächstes Jahr die Aussage wahrscheinlich nicht mehr richtig.


    Auf allen meinen NAS sind die crontab Einträge persistent, das betrifft QTS 4.2.6, 4.3.4 und 5.0.0!

    Und natürlich funktioniert crontab -e auch überall, nur muss der entsprechende Eintrag dann auch in die /etc/config/crontab eingetragen werden.

    Den crontab daemon habe ich nach einem crontab -e noch nie neu gestartet damit die Jobs laufen.


    Gruss

    Ich hab die QTS-Version 5.0.0.1932 (was eben die aktuellste mir derzeit zur Verfügung gestellt Version ist)


    Das Problem hab ich aber schon länger.

    Ich editiere die crontab hald immer direkt über vi, crontab -e geht meines Wissens doch nur lesend und dann müsste ich es ohnehin doppelt machen.

    Nein, crontab -e geht auf allen meinen NAS auch schreibend. Ich melde mich dazu aber als "admin" an, nicht als User, der in der Admin-Gruppe ist.

    Wobei das meiner Erinnerung nach auch geht.


    Mit crontab -e wird nur die aktuell laufende crontab editiert, das ist aber sofort nach Speicherung wirksam, bis zum Reboot.

    Reboot persistent wird das durch Eintragen in die /etc/config/crontab.


    Dann wäre die Frage seit wann das nicht mehr geht und was es für Besonderheiten zu diesem Zeitpunkt gab.

    Das die crontab nur "halb" gelesen wird, glaube ich nicht,

    Das wäre auch sehr ungewöhnlich. Es sei denn die Datei wäre korrupt, aber dann würde auch ein Restart des Daemons nichts daran ändern.


    Wie gesagt, läuft bei mir seit Jahren unverändert auf verschiedenen QTS Versionen.


    Gruss

    Zitat von blue_focus

    Ich editiere die crontab hald immer direkt über vi, crontab -e geht meines Wissens doch nur lesend und dann müsste ich es ohnehin doppelt machen.

    Das dürfte dein Problem sein. Nimm sudo crontab -e (ja, das funktioniert, wie FSC830 schon schreibt) und ziehe die Änderung auch in /etc/config/crontab nach.


    Ich sehe keinen Sinn darin, einen Fehler zu suchen, der vermutlich darin liegt, dass du vom ausdrücklich vorgeschriebenen Weg ("nicht /etc/crontab direkt ändern" - steht in jeder Linux-Doku, und in der von dir verlinkten Doku zu qts ebenfalls!) abweichst.

    Da steht genau, was wir sagen ^^.

    Wenn man nur crontab -e verwendet, dann ist das nach dem nächsten reboot weg.

    Um es persistent zu machen, muss man die Änderungen in der genannten Datei eintragen.


    Also entweder:

    crontab -e und /etc/config/crontab anpassen

    oder

    /etc/config/crontab anpassen und crondaemon neu starten


    Jacke wie Hose... :D


    Gruss

    OK, ich hab das so verstanden -> Finger Weg von crontab -e :D

    Ja ich bin hald ein Windows Mensch :p


    Aber ich mach ja mit der 2. Methode eigentlich auch nix falsch. Also mit vi die crontab anpassen und Service durchreißen.

    Also muss es da noch was Anderes haben.


    gibt es in QTS eigentlich auch ein Equivalent zu systemctl um zu schauen, welchen Status ein Service grade hat?

    Kenne hier nur qpkg_service. Aber das funktioniert ja nur für Apps und sagt nix über Systemdienste aus.

    Ich hole das nochmal hervor, weil ich das 1:1 auch kenne. Auch ich habe EIntrage in der crontab im Verzeichnis /etc/config getätigt - bereits vor Jahren und somit seit vielen FW-Versionen. Genau einer davon wird aber beim Neustart des NAS nicht ausgeführt. Auch ich muss daher nach jedem Neustart daran denken, crontab /etc/config/crontab && /etc/init.d/crond.sh restart explizit nochmal aufzurufen. Der betreffende Eintrag lautet:


    11 5,11,17,23 * * * /share/Web/autorun/XMLTV.sh


    Er taucht auch nach dem Neustart des NAS im Aufruf von crontab -e auf ohne dass ich vorher obiges ausführe. Da jeder Neustart aber immer mit einigem Aufwand verbunden ist habe ich keine Lust, hinsichtlich dieses Problems eine Versuchsreihe zu starten sondern finde mich eben damit ab. die Crontab jedesmal neu zu laden nach einem Reboot.

    Ich hab in der Crontab bislang nur einen Eintrag auskommentiert, das übersteht auch einen Reboot. Sonst habe ich da noch nichts angestellt.

    Was ist denn /share/Web/autorun für ein Verzeichnis? Manuell angelegt? Oder durch irgendeinen Prozess/App?

    Ich habe das Verzeichnis bei mir jetzt manuell erstellt, eine entsprechende Dateio angelegt und de Einträge in die crontab 1:1 übernommen.

    Da das NAS täglich bootet, kann ich Dir morgen sagen, ob es persistent ist oder nicht. ;)


    Gruss

    Das Verzeichnis /share/Web ist schon immer da. Ganz zu Anfangszeiten meines QNAP-Lebens hatte ich mal festgestellt, dass dies eines der Reboot-resistenten Verzeichnisse ist. Und da ich damals auch erste Schritte mit (internen) kleinen Web-Anwendungen für mein SmartHome auf dem NAS hatte, hat sich das Verzeichnis kurzerhand mit der Zeit für alles eigene etabliert. Beispielsweise liegen darin im von mir selber erstellten Unterverzeichnis autorun die Skripte, die ich eben auch in der autorun aufrufe.

    Zitat von duke-f

    Das Verzeichnis /share/Web ist schon immer da.

    Das ist die Standardfreigabe wenn der Webserver aktiviert ist / war. Ansonsten ist das share nicht vorhanden bzw. kann dann manuell (in der GUI) gelöscht werden.

    Jaaa, das ist klar, ich bezog mich eher auf den autorun-teil des Shares ^^ .

    Denn die autorun Dateien liegen bei mir woanders, unter ../.qpkg/autorun, daher die Nachfrage.


    Gruss

    Sicher gibt es da sinnvollere Orte - wie gesagt, war seinerzeit für mich logisch und hat sich seinerzeit einfach so etabliert.

    Zitat von duke-f

    Genau einer davon wird aber beim Neustart des NAS nicht ausgeführt.

    Bei Neustart werden keinerlei Befehle der Crontab ausgeführt. Erst wenn die angegebene Zeit erreicht ist.


    Zitat von duke-f

    Er taucht auch nach dem Neustart des NAS im Aufruf von crontab -e auf ohne dass ich vorher obiges ausführe.

    Und wird er denn dann zum nächsten Zeitpunkt ausgeführt?

    Da hast Du natürlich recht, war nicht sauber formuliert. Ich meinte, dass die Jobs nicht zur angegebenen Zeit ausgeführt werden.

    Das wundert mich, dass die Befehle in der aktiven Crontab stehen (diese wird nämlich mit crontab -e angesprochen) und dennoch nicht ausgführt werden.

    Ich hehe bisher ja davon aus, dass das Problem wieder vor dem Computer sitzt, komme aber einfach nicht drauf.

    Kannst Du den Inhalt des shell scriptes posten?


    Gruss