RPI3 - Crontab soll Shell-Skript aufrufen

  • Hallo liebes Forum,


    bevor ich zu meinem Problem komme, muss euch vermutlich erst mal etwas über das Projekt erzählen.
    Ich nutze eine PI-Cam mit IR-Filter-Switch.


    Mit dieser Cam und einem PI möchte ich eine Überwachungskamera realisieren.
    Ich nutze dafür Motion und das funktioniert so auch fehlerfrei.


    Diese Kamera lässt sich über die /boot/config.txt steuern.

    Bei Tag soll der IR-Filter nicht genutzt werden - also trägt man in die config.txt disable_camera_led=0 ein.

    Bei Nacht soll das Gegenteil erfolgen - also disable_camera_led=1.


    Hier beginnt mein Problem.

    Ich wollte über "crontab -e" einen Shellscript aufrufen, der die aktuelle "/boot/config.txt" umbenennt und die korrekte einsetzt.


    Also bei Tag-Modus:

    mv config.txt config_night.txt

    sleep 5

    mv config_day.txt config.txt

    sleep 5

    sudo reboot now


    Und im Nachmodus:

    mv config.txt config_day.txt

    sleep 5

    mv config_night.txt config.txt

    sleep 5

    sudo reboot now


    Ich habe festgestellt, dass die Scripte mit in dasselbe Verzeichnis müssen, da Sie sonst die config.txt nicht umbenennen können.

    Fand ich eigentlich nicht so geil, weil ich meine Skripte gern unter /home/pi hätte, aber ich war es leid kryptischen Fehlermeldungen nachzugehen.


    So liegen die beiden Sctipte also in "/boot".

    Die zeitliche Steuerung wollte ich über Crontab realisieren.


    Also unter "sudo crontab -e" folgendes eingetragen:


    10 20 * * * sudo sh /boot/cammodenight.sh

    10 6 * * * sudo sh /boot/cammodeday.sh


    Inhalt eines Scriptes: (hier wechsel von Nacht zu Tagmodus)

    Code
    #!bin/bash
    mv config.txt config_night.txt
    sleep 5
    mv config_day.txt config.txt
    sleep 5
    sudo reboot now



    Nun komme ich zu meinem Problem.

    Crontab ist nicht in der Lage, den Sctipt auszuführen, obwohl ich 777 auf die entsprechenden Dateien gelegt habe und alles mit sudo aufrufe.


    Gibt es vielleicht eine elegantere Lösung, um in der Config.txt den Eintrag "disable_camera_led=0" in "disable_camera_led=1" zu ändern?

    Wenn ich meine Scripte manuell ausführe funktioniert alles. Warum funktioniert es nicht mit Crontab?

    Warum ist es nicht möglich aus dem Verzeichnis /home/pi mit einem Script Dateien im Verzeichnis /boot/ mit mv umzubenennen?


    Vielen Dank für eure Hilfe.


    Grüße

    Ukognos

  • Inhalt eines Scriptes: (hier wechsel von Nacht zu Tagmodus)

    Code
    #!bin/bash
    mv config.txt config_night.txt
    sleep 5
    mv config_day.txt config.txt
    sleep 5
    sudo reboot now


    Nun komme ich zu meinem Problem.

    Crontab ist nicht in der Lage, den Sctipt auszuführen, obwohl ich 777 auf die entsprechenden Dateien gelegt habe und alles mit sudo aufrufe.

    Wenn Du eine root-crontab benutzt, wird sudo nicht benötigt. Benutze absolute Pfade, denn die crontab weiß evtl. nicht, wo sich die config.txt-Datei befindet.

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

  • Quote

    Ich habe festgestellt, dass die Scripte mit in dasselbe Verzeichnis müssen, da Sie sonst die config.txt nicht umbenennen können.

    Wie kommst du denn da drauf?

    Code
    mv /boot/config.txt /boot/config_night.txt

    funktioniert auch per Script ohne Probleme.


    Quote


    Ich habe festgestellt, dass die Scripte mit in dasselbe Verzeichnis müssen, da Sie sonst die config.txt nicht umbenennen können.

    Wie kommst du denn darauf?


    (sudo auf der Kommandozeile sollte verboten werden, die die Leute wissen nicht, was sie da machen.)


    Wo liegt dein Script?

    Wie hast du es in wessen Crontab aufgerufen?

    Selber denken,
    wie kann man nur?

  • hyle - Shebang repariert - vielen Dank - habe ich übersehen.


    Rasp-Berlin

    Gerne darfst du mich zwecks sudo erleuchten.

    Script liegt (wie im ersten Post beschrieben) in /boot.

    Wie ich darauf komme? Na ganz einfach durch Fehlermeldungen.

    mv: das Verschieben von '/boot/config.txt' in ein Unterverzeichnis

    seiner selbst ('/boot/config_night.txt'$'\r') ist nicht möglich

    Diese Fehlermeldung erhalte ich, wenn ich "mv /boot/config.txt /boot/config_night.txt" ausführe.


    rpi444

    Stimmt, danke dir. Ich werde das Sudo entfernen. Ich werde das mit den absoluten Pfaden probieren.

  • Gerne darfst du mich zwecks sudo erleuchten.

    sudo gibt dem berechtigten Nutzer root-Rechte.

    Das braucht man nicht, wenn der Prozess mit root ausgeführt wird und entsprechend von root die Berechtigungen erbt.

    sudo mit root ist doppelt gemoppelt.

  • Ich nutze eine PI-Cam mit IR-Filter-Switch.

    ....


    Gibt es vielleicht eine elegantere Lösung, ...

    Evtl. kannst Du auf diese regelmäßige Änderung der /boot/config.txt verzichten, wenn Du die Kommandozeilentools benutzt. Siehe z. B.: https://www.raspberrypi.org/do…an/applications/camera.md

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

  • Korrekt - habe die Dateien neu erstellt und nun läuft alles fehlerfrei.


    Mein Problem wurde gelöst - absolute Pfade waren notwendig.

    Vielen Dank.

    • Official Post

    Nur um das auch noch zu erwähnen...


    Wenn es nicht anders funktionieren sollte als über die /boot/config.txt, dann würde ich mit sed nur den Wert ändern und nicht immer die ganze Dateien kopieren. Das kann man auch in ein Skipt stecken und diesem den gewünschten Parameter 0 oder 1 übergeben.


    Bash: ir-cut_switch.sh
    #!/bin/bash
    
    sed -i "s/disable_camera_led=.*/disable_camera_led=$1/" /boot/config.txt
    
    sleep 5 && reboot


    Aufrufen würde man das Skript als root mit /Pfad/zu/ir-cut_switch.sh 1 bzw. /Pfad/zu/ir-cut_switch.sh 0.

  • ich würde da noch ein

    Code
    if [ $# -eq 0 ] 
      then 
        echo "Kein Wert angegeben, Abbruch."
        exit 1
    fi

    vorm sed einfügen, um zu verhindern, dass mit leerem Wert ein Reboot ausgelöst würde. Gäbe es dann einen Bootfehler?

    Menschen die keine Ironie verstehen finde ich super!

    • Official Post

    Du hast recht. Ich hab noch ein bissel erweitert:


    Gäbe es dann einen Bootfehler?

    Gute Frage, keine Ahnung! Ich kann es gerade nicht testen.