Skript startet nicht, wie erwartet

    • Neu

    872XT, QTS 5.2.2.2950, Raid 6 mit 6 HDD


    Der Aufruf eigener Skripte per autorun.sh ist in den Hardwareeinstellungen aktiviert.

    Bash: autorun.sh
    #!/bin/sh
# Warten, bis das Verzeichnis verfügbar ist
while [ ! -d "/share/CE_CACHEDEV1_DATA" ]; do
echo "Warte auf /share/CE_CACHEDEV1_DATA..."
sleep 5
done

# Skript ausführen, wenn das Verzeichnis verfügbar ist
/share/CE_CACHEDEV1_DATA/unterverzeichnis/datei.sh
    Code: datei.sh
    . /etc/profile.d/python3.bash
python3 /share/CE_CACHEDEV1_DATA/unterverzeichnis/versand.py

    versand.py überwacht ein bestimmtes Verzeichnis und versendet Dateien, die dort abgelegt werden, als e-mail-Anhänge an festgelegte Adressen. Funktionierte einwandfrei bis zum update auf 5.2.2.2950.


    Problem:

    versand.py wird nach dem Neustart des NAS nicht mehr abgearbeitet. Ich frage mit grep ab, der Prozess ist nicht aktiv. Wenn ich mich jedoch per terminal anmelde und datei.sh ausführe oder die Befehle aus datei.sh manuell eingebe, läuft versand.py wie beabsichtigt.


    Nach dem update habe ich dieses Problem mit einigen der sh/py-Skripte, die durch autorun.sh aufgerufen werden sollen, während andere nach dem Start ohne weiteres laufen.


    Danke vorab, alles Gute für 2025!

    • Neu

    Ermittel einmal mit which python3, wo das Programm python3 abgespeichert ist.

    Danach fügst du den kompletten Pfad mit in das Script vor den Befehl von python3.


    Das Problem am Ganzen, auf der Konsole gibt es Variable pathm in der die meisten Pfade zu den Progeammen aufgeführt sind und beim Aufruf eines Befehls wird in den verschiedenen Ordner gesucht und wenn auffindbar ausgeführt.

    Bei der Ausführung über die autorun.sh und anderen Startscripts wird nicht als Hilfe zur Ausführung nach den Programmen gesucht, sondern es wird vorausgesetzt, dass der Pfad zu den Programmen mit angegeben wird und somit direkt aufgerufen werden.

    • Neu
    Zitat von Eraser-EMC2-

    Ermittel einmal mit which python3, wo das Programm python3 abgespeichert ist.

    Danke. which hat zurückgegeben:

    Code
    /share/CE_CACHEDEV1_DATA/.qpkg/Python3/opt/python3/bin/python3


    Ich habe den Aufruf um diesen Pfad ergänzt, das Ergebnis ist unverändert. Wird die datei.sh während des Starts durch die autorun.sh aufgerufen (wie kann ich prüfen, ob das tatsächlich geschieht?), wird das python-skript nicht ausgeführt. Rufe ich die datei.sh über das Terminal auf, wird versand.py problemlos geladen und i Überwachung beginnt.

    • Neu

    Um die Frage noch abzuschließen:

    Probleme waren wohl darauf zurückzuführen, daß der Pfad zu Python3 nicht global gesetzt war.

    Anpassungen in /etc/profile oder .bashrc blieben zunächst erfolglos, da die Dateien beim Neustart neu geschrieben und die Anpassungen verworfen wurden.

    Geholfen hat letztlich, .bashrc durch die autorun.sh bei jedem Neustart aktualisieren zu lassen:

    Code
    export PATH=$PATH:/share/CE_CACHEDEV1_DATA/.qpkg/Python3/opt/python3/bin


    Dankeschön.

    • Neu

    Danke für die Rückmeldung.


    Ja, das Schreiben eines Autorun-Skriptes kann unerwartet kompliziert werden, da viele Skripte und Konfigurationsdateien bei jedem Systemstart neu zusammengebaut werden. Außerdem erfolgt der Aufruf von autorun.sh zu einem so frühen Zeitpunkt, an dem Vieles noch nicht initialisiert ist.


    Ein paar Tipps noch:


    Es empfiehlt sich, alle zukünftigen Erweiterungen in deiner datei.sh vorzunehmen, dann brauchst du autorun.sh nicht mehr anzufassen.


    Das Warten auf CE_CACHEDEV1_DATA kannst du dir sparen, wenn du ein Verzeichnis nimmst, dass es bereits beim Boot-Zeitpunkt gibt. Bei mir hat sich /mnt/HDA_ROOT/boot/ angeboten. Dann musst du von der Datei aber ein Backup machen, da HBS das Verzeichnis nicht erwischt.


    .bashrc automatisch zu ändern könnte überflüssig gewesen sein. Wenn du den Pfad in datei.sh mit export setzt, dann ist er in allen aus dieser Datei aufgerufenen Skripten verfügbar.


    Der Aufruf eines Skriptes lässt sich mit

    Code
    sh -x 2>/pfad/logfile skript.sh

    debuggen. Das hätte dich womöglich schneller zur Fehlerursache geführt.

    • Neu

    Von der Manipulation der autorun.sh bin ich mittlerweile auch wieder weg, nachdem ich mir a mal ein kleines Eigentor geschossen hatte. Die Definition der Pfade für virsh hat mir dann immer Unwegsamkeiten im Rahmen des Console-Menu gebracht, wo ich dann lange nach der Ursache gesucht habe.