Automatisierung über rc.local

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hallo Leute,
    ich beschäftige mich seit einigen Tagen mit meinem RasPi.
    Installariert ist RaspBian(NOOB). Ich greife per VNC darauf.
    Es steckt ein W-LAN Stick dran und manchmal eine RasPi Camera.

    Zuhause wenn der RasPi startet, lasse ich ein Laufwerk auf einer NAS über die "rc.local" mounten und danach ein Pythonscript ausführen, welches den ganzen Tag Fotos machen lässt, über Nacht ein Timelapse Video daraus macht, das fertige Video auf die NAS schiebt und die Fotos wieder löscht. So habe ich jeden Morgen ein 20MB Video vom letzten Tag auf der NAS liegen und der RasPi arbeitet weiter.

    Jetzt zum Problem: der Befehl für das mounten steht in der rc.local über em Befehl für Pythonscript ausführen. Wenn ich den RasPi jetzt ausserhalb meiner Wohnung starte, scheint er in der Zeile für das mounten auszusteigen (weil kein WLAN/Netzwerk verfügbar ist). Das Pythonscript wird also nicht ausgeführt.

    Gibt es eine Möglichkeit dass der RasPi die rc.local vollständig durchläuft auch wenn zwischenzeitlich Fehler auftauchen?

    Ich will nicht die Position für das mounten und Script ausführen tauschen (will jetzt nicht auf den Grund eingehen)

    Danke :)


  • Gibt es eine Möglichkeit dass der RasPi die rc.local vollständig durchläuft auch wenn zwischenzeitlich Fehler auftauchen?

    Das sollte der Fall sein, wenn die 1. Zeile in der rc.local, nicht verändert worden ist:

    Bash
    #!/bin/sh -e

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (1. Oktober 2014 um 10:28)

  • Das # in der ersten Zeile darfst du nicht wegnehmen, dann machst du die Datei kaputt denn dadurch wird der sog. Shebang identifiziert.

    Zeig mal bitte deine vollständige /etc/rc.local
    (bitte in CODE posten)


    /etc/rc.local ist ein gewöhnliches Script. Es gibt aber auch noch weitere Möglichkeiten etwas beim Systemstart automatisch starten zu lassen, siehe dazu hier: Automatisches Starten von Scripte / Programme ( Autostart )

    Das sollte der Fall sein, wenn die 1. Zeile in der rc.local, nicht verändert worden ist:

    Bash
    #!/bin/sh -e

    Nein.
    Das Script bleibt stehen solange ein Befehl nicht beendet wurde - es sei denn man schickt es in den Hintergrund zB mit einem & am Ende der jeweiligen Befehls-Zeile dann wird nicht gewartet bis es fertig ist.
    -e bewirkt etwas anderes:

    Zitat

    If not interactive, exit immediately if any untested command fails.
    The exit status of a command is considered to be explicitly tested if the command is used to control an if, elif, while, or until; or if the command is the left hand operand of an or operator.

    -> man sh

  • Hallo Meigrafd, danke für die ausführliche Antwort.
    So sieht die rc.local aus, mit der die Sache funktioniert.

    Erst wir ein Laufwerk gemountet, dann der VNC-Server gestartet und dann das Python-Script (auf nem USB-Stick)

    Ich habe gerade, das # wieder ergänzt und den RasPi OHNE WLAN gestartet. Das Python-Script wird NICHT ausgeführt. Die Kamera macht keine Fotos.
    Dann MIT WLAN gestartet und siehe da, die Kamera macht Fotos.
    Das Netzlaufwerk ist gemountet und VNC läuft auch wie gewünscht.
    (ohne "Sleep 30" wird das Script garnicht ausgeführt. Vermute, dass der RasPi den USB-Stick noch nicht eingebunden hat)

    Ohne # in der rc.local klappt alles mit und ohne WLAN.

    Nachtrag:
    habe das # am Anfang wieder ergänzt und hinter "mount" und "vncserver" ein "&" hinzugefügt (wie in deinem Kommentar). Jetzt scheint alles zu laufen :)
    Die nächsten Tage werden es zeigen.
    :danke_ATDE:

    Einmal editiert, zuletzt von insidERR (1. Oktober 2014 um 23:22)

  • So wie die Datei aktuell ist wird sie 100% nicht funktionieren.

    Wie gesagt legt die erste Zeile den Shebang fest und der muss mit vorangestelltem # da stehen: #!/bin/sh

    Desweiteren wird die Datei bereits mit root Rechten ausgeführt, also ist sudo dort überflüssig.

    Und zu guter letzt ist es in einem Script wie gesagt so das die Befehle nach einander abgearbeitet werden. Erst wenn der vorherige Befehl beendet wurde wir der nächste ausgeführt - es sei denn man schickt den Befehl in den Hintergrund und wartet somit nicht auf dessen Rückgabe (vorallem weil die /etc/rc.local komplett beendet wird sobald einer der Befehle einen Fehler verursacht).

    Also wenn dann änderst du die /etc/rc.local bitte wie folgt
    (über die Konsole bearbeiten! NICHT die Datei überschreiben!!)

    [USER] , [PWD] und [SERVER-IP] aber natürlich mit richtigen Werten ersetzen.

  • Hallo Leute,

    meigrafd Ich könnte mir schon vorstellen dass das so funktioniert.
    Ich habe dazu eine kleine Theorie :)
    Die rc.local wird ja sowieso von einer Shell(/bin/sh ?) aufgerufen und auch von dieser interpretiert. Wenn in der ersten Zeile kein Shebang angegeben wird bedeutet dass ja nur dass die aufrufende Shell das Skript interpretieren muss(und nicht die vom Shebang definierte). Ich hätte auch gedacht dass der "kaputte" Shebang eher zu einem Synthax Error oder so führt aber es scheint als ob der er einfach ignoriert wird. Dabei wird natürlich auch die Option -e ignoriert. Und um nicht zu lang um den heißen Brei zu schreiben Poste ich schnell was ich dazu gefunden habe:

    Zitat

    http://wiki.ubuntuusers.de/rc.local#Problembehebung
    Des Weiteren kann es passieren, dass die Datei nicht vollständig ausgeführt wird. Dazu kommt es, wenn einer der eingefügten Befehle einen Fehler erzeugt (Returncode != 0). Da in der ersten Zeile #!/bin/sh -e standardmäßig die Option -e angegeben ist, wird die Ausführung sofort abgebrochen. Um dieses Verhalten abzustellen, verkürzt man die 1. Zeile auf #!/bin/sh.

    Ich könnte mir vorstellen dass genau das passiert ist. Die rc.local wird mit /bin/sh und eben nicht mit "/bin/sh -e" geparst. Das erklärt auch wieso das Python Skript das eine mal(mount Befehl erfolgreich) ausgeführt wird und das andere mal nicht(mount Befehl schlägt fehl).

    Das alles ändert aber nichts an der Tatsache dass vor "!/bin/sh -e" auf jeden Fall ein "#" gehört! ;)


    insidERR Würde es dir etwas ausmachen das ganze kurz zu überprüfen?
    Dazu müsstest du deine rc.local nochmal so ändern dass in der ersten Zeile nur "#!/bin/sh" steht. Also wie vorhin, nur ohne "-e" und mit "#". Wenn du dann den Raspi neu startest müsste eigentlich alles genauso wie davor funktionieren. Gib uns bitte bescheid ob das geklappt hat.

    Als nächstes würde ich den mount Befehl aus der rc.local herausnehmen. Um automatisch Laufwerke zu mounten gibt es unter Linux eine eigene Konfigurationsdatei names "fstab". [http://wiki.ubuntuusers.de/fstab]. Hier im Forum gibts auch ein paar Threads dazu. (Hier ist zum Beispiel einer)


    meigrafd Ich könnte mir Vorstellen dass das starten der Prozesse im Hintergrund durch die benutzung der fstab gar nicht mehr nötig ist, da es m.M.n ja nur ein problem mit dem mount Befehl gibt. Müsste man aber auf jeden Fall testen!
    Du hast auch einen kleinen Fehler im Code gemacht. Die Zeile

    Code
    ( sleep 30; python /media/RASPI/Autostart.py #Ein Pythonscript auf nem USB-Stick (FAT32) ) &


    gehört eigentlich so

    Code
    ( sleep 30; python /media/RASPI/Autostart.py ) &  #Ein Pythonscript auf nem USB-Stick (FAT32)

    Grüsse,
    Joh

    DON'T PANIC!

    Einmal editiert, zuletzt von joh.raspi (2. Oktober 2014 um 02:41)

  • Nein.
    Die Datei ansich ist ausführbar und wird nicht an einen Interpreter übergeben sondern direkt ausgeführt und somit spielt der SheBang eine entscheidene Rolle. Das kann man einfach testen indem man der Datei die Ausführrechte entzieht und rebootet, dann sieht man das sie nicht mehr ausgeführt wird.

    Das Parameter -e ist eine zusätzliche Option für sh.
    Das hat nichts damit zu tun das die Datei ansich mit /bin/sh parsed wird. -e sorgt dafür dass das ganze Script sofort beendet wird sobald einer der Befehle fehlschlägt - das kannst du in man sh nachlesen und habe ich oben bereits gepostet.
    Nimmst du -e weg würde er den nächsten Befehl auch ausführen obwohl der vorherige fehlerhaft war.


    Mit dem Fehler in der letzten Zeile hast du allerdings Recht, das hab ich verbockt :blush:

  • Hallo zusammen,
    danke für eure Antworten.
    Ich bin ein eingefleischter WindowsUser und programmiere in VB6/VBA/.NET :shy:
    Muss mich in die Linux/Python-Welt noch einarbeiten.

    Also wie gesagt, die Version mit dem ohne "#" (Lool, was für ne Ausdrucksweise) funktioniert .
    Ich habe jetzt das # wieder ergänzt und auch das & am Ende der Befehle. Jetzt läufts auch.

    joh.raspi: werde heute Abend das # und -e in der ersten Zeile entfernen, dann mit und ohne WLAN starten. Gucken ob die Kamera Fotos macht und das Ergebnis hier posten.
    Den Mountbefehl werde ich auch verschieben.
    :danke_ATDE:

    Kurze Zwischenfrage: warum steht

    Code
    ( sleep 30; python /media/RASPI/Autostart.py )

    in Klammern? Irgendeine Sonderbehandlung, oder damit man beide Befehle in eine Zeile schreiben kann? ( ; ist der Befehltrenner)


  • Wenn in der ersten Zeile kein Shebang angegeben wird bedeutet dass ja nur dass die aufrufende Shell das Skript interpretieren muss(und nicht die vom Shebang definierte).

    Ja, das kannst Du dir auch anzeigen lassen, welche aufrufende/interpretierende Shell von einem ausführbaren (z. B. chmod 755 ...) Script das kein SheBang hat, benutzt wird. Z. B. mit:

    Code
    logger "$0 - benutzte shell: `ps -fP $$`"


    als erste wirksame Zeile im ausführbaren Script (ohne Shebang), oder/und

    Code
    echo "$0 - benutzte shell: `ps -fP $$`"
    Code
    cat /var/log/syslog | grep -i logger

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (2. Oktober 2014 um 09:50)


  • Kurze Zwischenfrage: warum steht

    Code
    ( sleep 30; python /media/RASPI/Autostart.py )

    in Klammern? Irgendeine Sonderbehandlung, oder damit man beide Befehle in eine Zeile schreiben kann? ( ; ist der Befehltrenner)

    Die ( ) bewirkt das die Befehle in einer Gruppe zusammengefasst werden und ; dient als Befehlstrenner ähnlich wie && mit dem Unterschied das der nachfolgende Befehl den vorherigen exitcode ignoriert -> Würde man beispielsweise ls-la && echo ja ausführen, würde der nachfolgende Befehl "echo ja" nicht ausgeführt werden weil der vorherige einen Fehler produziert hat. Würde man aber ls-la ; echo ja ausführen so würde "echo ja" trotzdem ausgeführt werden obwohl der vorherige eine Fehlermeldung ausgeworfen hat.

    Insgesamt sieht die Zeile ja so aus:

    Code
    ( sleep 30; python /media/RASPI/Autostart.py ) &

    Was wie gesagt bewirkt das die ganze Gruppe durch das am Ende stehende & in den Hintergrund geschickt und nicht auf dessen Ende gewartet wird.
    Würde man die ( ) weg lassen, würde das Script 30 Sekunden pausieren (wegen des sleep's) und erst danach das Python Script in den Hintergrund schicken.
    Durch das Gruppieren beschleunigt man also die Verarbeitung des Scripts, da nachfolgende Zeilen ungebremst abgearbeitet werden können.


    PS: Bezüglich exitcode siehe vorletzter Spoiler >> hier <<


  • Nein.
    Die Datei ansich ist ausführbar und wird nicht an einen Interpreter übergeben sondern direkt ausgeführt ...


    Doch. :)
    Um meine Theorie zu überprüfen habe ich das ganze gerde mit logger selbst getestet. ( rpi444 Danke, logger ist echt super :thumbs1: Kannte ich (wie so vieles) noch nicht. Ich hätte das jetzt in eine Datei geloggt :rolleyes: )

    Mit korrektem SheBang wird die rc.local wie folgt aufgerufen:

    Code
    /bin/sh -e /etc/rc.local


    Ohne (oder mit ungültigem) SheBang so:

    Code
    /bin/sh /etc/rc.local


    rpi444, noch eine kleine Korrektur zu deinem Codebeispiel

    Code
    cat /var/log/syslog | grep -i logger


    funktioniert so natürlich nicht. Das war wohl so

    Code
    cat /var/log/syslog | grep "benutzte shell"


    gemeint. ;)



    Nimmst du -e weg würde er den nächsten Befehl auch ausführen obwohl der vorherige fehlerhaft war.


    Was auch in diesem Fall "gewollt" war/ist.


    insidERR Du musst das also nicht mehr testen. Was ich an deiner Stelle aber jetzt machen würde ist den SheBang wieder so zu ändern wie er ursprünglich war, dann das mounten in die fstab auslagern und anschließend das Python Skript wie von meigrafd beschreiben im Hintergrund starten.

    Joh

    DON'T PANIC!

    Einmal editiert, zuletzt von joh.raspi (2. Oktober 2014 um 15:56)


  • rpi444, noch eine kleine Korrektur zu deinem Codebeispiel

    Code
    cat /var/log/syslog | grep -i logger


    funktioniert so natürlich nicht. Das war wohl so

    Code
    cat /var/log/syslog | grep "benutzte shell"


    gemeint. ;)

    Nein, das war schon so gemeint und funktioniert mit logger ganz gut. Z. B.:

    Code
    :~$ logread | grep -i logger
    Oct  2 15:55:44 YYYY user.notice logger: ./footest.sh - benutzte shell: UID        PID  PPID PSR  C STIME TTY      STAT   TIME CMD xxx        3615  2254   0  0 15:55 pts/3    S+     0:00 /bin/bash

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

Jetzt mitmachen!

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