Autostart mit rc.local oder crontab

  • Guten Abend, ich habe ein kleines Skript erstellt, welches immer nach dem booten ausgeführt werden soll.

    das ganze sieht so aus:

    Bash
    #!/bin/sh
    
    
    /home/pi/dienste/rede yooooooo
    gpio  export 22 out
    gpio -g write 22 0

    (rede ist eine Text to speech Funktion, die ich selber erstellt hab)

    ich habe es folgendermassen mit der der rc.local versucht

    :

    jedoch wird nur meine Redefunktion ausgeführt und die LEDs bleiben dunkel :s

    beim ausführen der rc.local funktioniert alles wie es sollte.

    danach habe ich es als root (mit sudo su) und cronjob -e versucht:

    mit genau dem gleichen Resultat: rede funktioniert, leds nicht.

    bitte um hilfe:)

    mfg

  • vielleicht einfach deshalb, weil die Anode der LED auf +3,3V liegt und die Kathode (über Vorwiderstand) mit dem GPIO verbunden ist (ohne dies jetzt irgendwie aus den Angaben des TE konkret nachvollzogen zu haben). Jedenfalls leuchtet bei so einer Beschaltung die LED, wenn am GPIO-Ausgang 0 (low) angesteuert wird. Mit 1 ist sie aus...

  • Ich würde erst mal hinterfragen ob das Script so überhaupt funktioniert bzw ausgeführt werden kann. Wenn es manuell mit exakt dem selben Eintrag wie in /etc/rc.local nicht funktioniert kann crontab oder /etc/rc.local auch nicht zaubern.
    Wenn er es manuell ausführen kann aber das WIE anders aussieht, sprich er übergibt die Datei dem Interpreter "sh" oder "bash", dann ist das nicht die selbe Art und Weise wie er es aktuell über /etc/rc.local ausführt.

    Was die Crontabeinträge /tmp/001 usw uns sagen sollen steht auch in den Sternen


    FAQ => Nützliche Links / Linksammlung => Autostart

  • Ich kann aus dem Beitrag nicht raus lesen WIE er das Script manuell ausführt.


    beim ausführen der rc.local funktioniert alles wie es sollte.

    Das ist etwas mager

    Fraglich wäre: Was ist der Unterschied zwischen manueller Ausführung und der automatischen?

    /etc/rc.local ist ein Script. Es muss Ausführrechte besitzen sowie am Ende muss "exit 0" in der Datei stehen. Ein Shebang muss ebenfalls gesetzt sein. Das Script wird als root ausgeführt, sudo ist also unnötig. root darf generell alles.

    Was in /home/pi/dienste/rede drin steht bzw ob das ggf ein Fehler verursacht ist ebenfalls relevant, auch das Er es derzeit so geschrieben hat das seine "Redefunktion" das Script blockiert, es wird also gewartet bis "rede" beendet wurde bevor nachfolgende Zeilen abgearbeitet werden.

  • Unabhängig von meigrafd's Ausführungen, die unbedingt zu beachten sind, sollte man, wie schnoefftel sagt, gerade im Zusammenhang mit Autostart immer absolute Pfadangaben verwenden


    man sollte sich angewöhnen, immer absolute Pfadangaben zu nutzen.

    Ich habe die Erfahrung gemacht, dass das "working directory" im Autostart-Prozess /home/pi lautet (glaube ich), auch wenn das Script sich eigentlich in einem anderen Verzeichnis befindet und selbst dann, wenn in /etc/rc.local das Script über eine absolute Pfadangabe gestartet wird! Dies ist im Scriptcode (also intern) zu beachten...

  • Bash
    #!/bin/sh
    
    
    /home/pi/dienste/rede yooooooo
    gpio  export 22 out
    gpio -g write 22 0

    Wenn 'rede' ein Langläufer ist, der sich nicht selber nach ein paar Sekunden und erfolgreicher Arbeit beendet, hat das meines Erachtens nichts in der rc.local zu suchen. Der Nachteil bei "forking" ist, dass eine Unit NICHT sofort zurückkommt, sondern darauf wartet, dass der Job irgendwann beendet wird. Etliche Folge-Prozesse könnten davon beeinträchtigt werden, bis hin zu multi-user.target, welches den erfolgreichen Start des Multi-User-Systems bestätigt..... und die rc.local wird mit "forking" gestartet.

    Du könntest vielleicht noch eine schmutzige Variante versuchen, und zwar 'rede' hier einfach in den Hintergrund verschieben, damit würde dann wenigstens der Bootprozess ordentlich weiterlaufen.

    Code
    /home/pi/dienste/rede yooooooo &

    Abschließend.... Du solltest jedes Script mit einem "exit 0" beenden, wenn es erfolgreich beendet wurde. Jeder andere (auch fehlende) Return-Code wird mit "Job failed" festgestellt und löst eine Fehlerbehandlung von systemd aus, die sicherlich unerwünscht ist, wenn der Job OK war.

    Einmal editiert, zuletzt von WinterUnit16246 (19. November 2016 um 20:26)

  • Guten Abend, erstmal danke für die Vielen antworten:)


    1.) wenn ich mein satus.sh script manuell ausführe funktioniert alles wie es sollte. ( das ist eine RGB red, mit common anode oder kathode, bin mir nichtmehr sicher, deshalb kann mein script von euren abweichen:) also keine Bange, manuell funktionierts.
    zu der frage wie ich es ausführe : per ssh einloggen ; und dann /home/pi/dienste/status.sh

    tatsächlich ist rede eine funktion, die etwas länger dauert. (ca 3 sec)

    es lag jetzt wohl an den unvollständigen Pfaden der GPIO befehle..., habe das angepasst und jetzt funktionierts. DANKE!

    jetzt gehts weiter:
    ich habe ein Java Programm, welches einen Bewegungsmelder steuert. dieses sollte beim Systemstart gestartet werden und läuft dann ständig im Hintergrund.

    wie kann ich das in mein status.sh Autostart-script einbauen?
    (Am besten so, dass das Output dieses Java Programms in ein vorher definiertes .txt - file geschrieben wird. ) :blush:

    bis jetzt mach ich das MANUELL folgendermassen :

    Code
    sudo nohup java -jar /home/pi/geraete/bewegungssensor/RaspBewegungsmelder.jar&

    das funktioniert aber derzeit auch nur, wenn ich diesen Befehl (per skript oder wirlich per Befehl) in dem Verzeichnis ausführe in dem die JAVA datei auch wirlich liegt :s
    das kanns ja auch nicht sein. Vielen Dank schonmal:)


  • Du solltest jedes Script mit einem "exit 0" beenden, wenn es erfolgreich beendet wurde. Jeder andere (auch fehlende) Return-Code wird mit "Job failed" festgestellt und löst eine Fehlerbehandlung von systemd aus, die sicherlich unerwünscht ist, wenn der Job OK war.

    Auch hier muss ich noch mal nachhaken: Was verstehst Du denn unter einem "fehlende(n)" Return-Code? M.W. gibt jedes Skript prinzipiell immer einen Return-Code zurück - entweder den explizit per "exit <n>" angegebenen oder den des letzten aufgerufenen Befehls. Wenn das Skript ohne Fehler durchläuft, sollte das in beiden Fällen "0" sein und vom aufgerufenen Prozess eigentlich nicht unterschieden werden können.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!