Verzögertes Skript in autorun.sh initiieren

    TVS 872-XT

    QTS 5.1.5.2645

    QTS/Apps auf Raid1

    Nutzerdaten auf Raid 6


    Im Ergebnis soll beim Starten des NAS ein Skript gestartet werden, welches ein Verzeichnis überwacht, zugehende Dateien umbenennt und in einer MySQL-Datenbank einen Datensatz anlegt, der u.a. den Link zu der Datei enthält.

    Code: autorun.sh
    /share/CE_CACHEDEV1_DATA/autostart/beispiel-1.sh
    Code: /share/CE_CACHEDEV1_DATA/autostart/beispiel-1.sh
    sleep 600
. /etc/profile.d/python3.bash
python3 /share/CE_CACHEDEV1_DATA/autostart/Pythonskript.py

    /share/CE_CACHEDEV1_DATA/autostart/Pythonskript.py:

    Überwacht Verzeichnis und benennt eingehende Dateien um


    Die 600 Sekunden sollen dem System Zeit geben, Python zu laden, bevor das Pythonskript.py ausgeführt wird.


    Wenn ich /tmp/config mounte und autorun.sh manuell ausführe, funktioniert es.


    Nach dem unmount und dem Neustart des Systems scheint es einen Bruch zischen der autorun.sh und der beispiel-1.sh zu geben. Die Pythonskript.py wird nicht automatisch aufgerufen, nur wenn ich beispiel-1.sh manuell per Terminal starte.


    Vorschläge? Danke!

    gelöst.


    • Systemsteuerung/Hardware - automatischen Start ... deaktiviert
    • "runlast" installiert
    • Das Paket legt Verzeichnisse an. Skripte, die in diesen Verzeichnissen hinterlegt werden, ruft runlast beim Systemstart erst nach QPKG re-Integration
    • einfach einzubinden

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

    Das Problem ist jetzt zwar schon gelöst, aber vermutlich hätte es genügt, python3 mit kompletten Pfad anzugeben. Wenn autorun.sh vom System aufgerufen wird, ist der Suchpfad möglicherweise noch nicht gesetzt.


    Python braucht auch nicht vorweg geladen zu werden, sondern ist direkt aufrufbar. (Welche Voraussetzungen für dein Pythonskript gelten, weiß ich natürlich nicht.)

    Zitat von Anthracite

    python3 mit kompletten Pfad anzugeben

    Danke. Da wüßte ich gar nicht, wo ich suchen soll. Ht das hier etwas damit zu tun?:

    Code
    "# . /etc/profile.d/python3.bash"


    Ich hatte in zahlreichen Beiträgen davon gelesen, daß autorun.sh abgearbeitet wird vor

    Code
    "QPKG re-integration during QTS NAS bootup"

    Ich hatte auch versucht, das mittels "sleep 600" in der autorun.sh oder einem nachgelagertem Shell-Skript zu lösen, aber das war alles erfolglos.


    Zu dem Python: Ich habe das "watchdog"-Modul eingebunden. QTS Appstore(?) bietet ein Python 2.x und ein 3.x. Watchdog erfordert 3.x. Das habe ich auch installiert. Aus irgendwelchen Gründen ist aber o.a. Befehl

    (/etc/profile.d...) erforderlich, sonst bekomme ich nach python3 ... eine

    Code
    "no such command"

    Fehlermeldung zurück.

    Die Suchpfade funktionieren nur in der Konsole. Sobald man Scripte durch crontab, QPKGs oder durch die autorun gestartet werden, müssen die Programmaufrufe mit dem kompletten Pfad des Programmes oder Scriptes verwendet werden.

    Evtl. gibt es auch die Möglichkeit das Profil von der der autorun aufzurufen, damit man die Suchpfade auch im Script nutzen kann, aber das weiß ich nicht.

    Zitat von BillBeaver

    Ht das hier etwas damit zu tun?:

    Das kann gut sein. Da ist der Aufruf eines Skriptes auskommentiert, und in dem Skript wird der Suchpfad (zum Teil?) gesetzt. Nimm mal das # und das Leerzeichen weg, so dass der Punkt das erste Zeichen in der Zeile ist und probier aus, vllt. geht es dann schon.


    Zitat von Eraser-EMC2-

    Evtl. gibt es auch die Möglichkeit das Profil von der der autorun aufzurufen, damit man die Suchpfade auch im Script nutzen kann

    Ja, das geht, z. B.

    Code
    . /etc/profile

    oder

    Code
    . /share/homes/userxxxx/.profile

    je nachdem, wo der Suchpfad definiert ist. Wichtig sind . und Leerzeichen vor dem Pfad uns Namen des Skriptes, damit die im Skript gemachten Pfad- und Variablenänderungen auch im aufrufenden Prozess bekannt sind. Die so gemachten Änderungen gelten dann im aufrufenden Prozess und allen von ihm gestarteten Prozessen, nicht aber in anderen unabhängig davon gestarteten Prozessen.