Beiträge von xelra

    Zitat von "winklernorbert28"
    Code
    ...
    
    
    start()
    {
       echo "Starting "
       /mnt/HDA_ROOT/.config/cs/bin/./oscam -b -c /mnt/HDA_ROOT/.config/cs/etc
    }
     
    ...


    Bitte um Hilfe. Irgendwas mache ich falsch


    Der Pfad ist doch bestimmt <somepath>/bin/oscam und nicht <somepath>/bin/./oscam


    . bedeutet "dieses Verzeichnis". Genauso wie .. "Mutterverzeichnis" bedeutet. Daher ja auch "cd ..". Wenn du "cd ." tippst, dann landest du im selben Verzeichnis.


    Als Shell-Neuling hat dich das bestimmt verwirrt, weil du wohl oscam mit dem Befehl "./oscam" von Hand gestartet hattest.

    Habe das Problem vollstädnig gelöst.


    Meine Vermutung war, dass die Einstellungen aus der /etc/profile evtl. vor der autorun.sh laufen und dann auf jeden Fall erst nach den init-Scripts wieder.


    Daher ist die Zeile


    Code
    #set environment variablesecho "export PATH=$PATH:/opt/bin:/opt/sbin:/usr/local/sbin" >> /etc/profile


    in der autorun.sh für die init-Scripts ohne Effekt.
    Ich habe die autorun.sh angepasst:


    Code
    #set environment variables
    echo "export PATH=$PATH:/opt/bin:/opt/sbin:/usr/local/sbin" >> /etc/profile
    export PATH=$PATH:/opt/bin:/opt/sbin:/usr/local/sbin


    Auf die Art und Weise funktioniert jetzt alles. Auch das ursprüngliche Problem mit /opt/bin/su anstelle von einfach nur su ergibt sich damit nicht mehr.
    Ich denke, dass das ein generell gültiger bugfix ist und vielleicht auf Seite 1 dieses Threads in die Musterversion der autorun.sh aufgenommen werden sollte.


    Jetzt bin ich glücklich. Vielen Dank für das Script. :mrgreen:

    Hallo,


    jetzt bin ichs nochmal.


    Das Problem mit der Umgebungsvariablen scheint leider weitere Kreise zu ziehen.


    Ich hatte es ja so gelöst, dass ich ein


    Code
    /opt/bin/su


    ins Script geschrieben habe. Aber jetzt ist es so, dass beim Starten von SABnzbd es dann auch die Programme unrar und par2 nicht findet. Die befinden sich auch in /opt/bin.


    Starte ich dagegen nachher nochmal SABnzbd von Hand, dann werden unrar und par2 gefunden und SABnzbd funktioniert einwandfrei.


    Code
    /opt/etc/init.d/S20sabnzbd restart


    Ich habe dann natürlich gleich mal in die /etc/profile geschaut. Dort stehen /opt/bin und /opt/sbin im Pfad. Also sind Sie ja dort auch von der autorun.sh erfolgriech hinexportiert worden und das ja zwangsweise auch VOR dem Ausführen des init-Scripts.


    Hat jemand eine Idee? Lösung?


    Achja, und das QPKG habe ich auch deaktiviert, weil nach deiner Beschreibung Terz, könnte das mit rm -Rf /opt ja genau das Problem sein.

    Hallo Terz,


    vielen Dank für deinen Post. Als ich deinen Code gesehen habe, da ist mir sofort ein kleiner aber wichtiger Unterschied aufgefallen, den ich gleich getestet habe, noch bevor ich das mit der log-Datei gemacht habe.


    Und zwar stand bei mir


    Code
    su


    und bei dir stand


    Code
    /opt/bin/su

    .


    Ich habe das geändert und jetzt geht es auch beim Start. Also ist es wohl so, dass hier die Pfad-Variable erst nach der autostart.sh angelegt wird.


    Ich freu mich, dass es jetzt geht. Danke für dein Script und dafür, dass du dich mit meinem Problemchen befasst hast.

    Hallo priewald,


    ich habe deinen Tipp ausprobiert, aber leider hat es nichts geändert.


    Ich bin mir sicher, dass die scripts laufen beim boot, weil die log-Einträge sind ja da.


    Code
    411,"Information","2011-07-02","13:34:22","System","127.0.0.1","localhost","Starting SABnzbd"
    410,"Information","2011-07-02","13:34:21","System","127.0.0.1","localhost","Starting Transmission"
    409,"Information","2011-07-02","13:32:07","System","127.0.0.1","localhost","System started."
    408,"Information","2011-07-02","13:29:54","System","127.0.0.1","localhost","System was shut down on Sat Jul  2 13:29:54 CEST 2011."


    Nur die daemons starten eben nicht mit beim boot. Starte ich das script dann direkt nach dem boot von Hand, dann geht alles.

    Hi,


    ich habe genau das selbe Problem wie jmberg. Die scripts funtionieren, wenn ich Sie per Hand starte. Und wenn ich die autorun.sh von Hand starte funktionieren die Scripts auch.


    Wenn ich jetzt aber das NAS neustarte, dann laufen zwar die Scripts auch, was ich am logging-Eintrag sehen kann, aber Sie tun nicht ihren Dienst.


    Hier die beiden Scripts die ich automatisch starten lassen will.


    Code
    [/opt/etc/init.d] # cat S10transmission#!/bin/shTRANSMISSION_BIN=/opt/bin/transmission-daemonTRANSMISSION_CONFIG_DIR=/opt/etc/transmissionTRANSMISSION_USER=transmissionNAME="Transmission"start(){   echo "Starting ${NAME}"   /sbin/log_tool -a "Starting ${NAME}" -t 0 -u System -m localhost   su $TRANSMISSION_USER -c "EVENT_NOEPOLL=0 $TRANSMISSION_BIN --config-dir $TRANSMISSION_CONFIG_DIR"}stop(){   echo "Shutting down ${NAME}"   /sbin/log_tool -a "Shutting down ${NAME}" -t 0 -u System -m localhost   if [ -n "`pidof transmission-daemon`" ]; then           kill -9 `pidof transmission-daemon`  fi}# you do not need to edit this linescase "$1" in    start)        start        ;;    stop)        stop        ;;    restart)        # Restarting the Daemon        $0 stop        $0 start        ;;    *)        ## If no parameters are given, print which are avaiable.        echo "Usage: $0 {start|stop|restart}"        exit 1        ;;esac



    Ich bin mir wirklich unschlüssig woran das Problem liegt. Da ich ja aber die log-Einträge habe und daher weiß, dass beim Neustart die Scripts laufen, gehe ich davon aus, dass aus irgendeinem Grund das Starten der daemons beim booten scheitert. Ich weiß aber nicht warum, oder wie ich jetzt hier am besten vorgehe.
    Nach dem Bootvorgang funktioniert das Starten der Daemons ja dann mit den Scripts. Also wenn ich es dann nochmal per Hand "anstoße".


    Ich wäre sehr dankbar für Rat.


    Außedem vielen Dank für die autorun.sh. Wenn es für mich funktionieren würde, dann ist das wirklich eine super Sache. Vor allem, weil man wieder die gewohnte Abstraktionsebene mit den init-scripts bekommt. Das ist einfach eine super und professionelle Lösung. Die autorun.sh sollte in der Form schon Standard in der Firmware sein. TOP!