Problem mit Cronetab

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hallo zusammen,

    ich bin immer noch blutiger Anfänger. Ich habe lange Zeit nichts mehr am Pi machen müssen.

    Installiert hatte ich das damals auf Whezzy und regelmäßig updates/upgrades gefahren (neuster Stand war also Strech).

    Jetzt ist leider die SD-Karte nach einem Netzausfall defekt und mein Backup ist unvollständig :(

    Das Problem welches ich jetzt habe, hatte ich so ähnlich schon einmal (zu whezzy zeiten) und geglaubt es gelöst zu haben.

    Ich habe jetzt meinen Pi3 mit Rasbian Strech neu aufgesetzt und möchte meine bewährtes Lufterskript wieder laufen lassen.

    Ich habe an gpio18 einen Lüfter hängen (via Schaltung natürich).

    Nach dem neuen Image und entsrechenden updates habe ich dann folgendes gemacht:

    1. Unter /usr/local/bin das luefterskript.sh erstellt.

    2. Unter sudo nano /etc/rc.local habe ich folgendes ergänzt:

    Code
    echo "18" > /sys/class/gpio/export
    Chmod 666 /sys/class/gpio/gpio18/value && sudo chmod 666 /sys/class/gpio/gpio18/direction
    echo "out" > /sys/class/gpio/gpio18/direction

    3. Quellcode von sudo nano luefterskript.sh ergibt:

    4. via crontab -e

    Somit ergibt crontab -l:

    Der Befehl sudo nano /var/log/syslog ergibt:

    Code
    Jun 14 17:05:01 raspberrypi CRON[1060]: (pi) CMD (/usr/local/bin/luefterskript.sh)
    Jun 14 17:05:01 raspberrypi CRON[1056]: (CRON) info (No MTA installed, discarding output)

    Der Befehl sudo journalctl -n 5 -u cron  ergibt

    Das Skript an sich fuktioniert mit dem Befehl bash -x /usr/local/bin/luefterskript.sh

    So wie ich es sehe stößt crone dieses auch an, aber es funktioniert einfach nicht automatisch...


    Kann mir bitte jemand helfen? Ich stehe echt auf dem Schlauch. Mit dem alten Image hat es noch so funktioniert. Ich hatte mir das alles so notiert.....


    Ich habe mich bezüglich MTA mal informiert. Ich habe ohne weiteres keine Möglichkeit eine Email zu integrieren. Muss das überhaubt sein?

  • Ist luefterskript.sh denn ausführbar? Das siehst Du, wenn in der Ausgabe von ls -l /usr/local/bin/luefterskript.sh in der 4. Spalte ein "x" steht. Falls nicht kannst Du das mit sudo chmod u+x /usr/local/bin/luefterskript.sh ändern.

    • Offizieller Beitrag

    Hab erstmal nur überflogen...

    - sudo nano luefterskript.sh ist sudo nötig?

    Wenn ja, dann musst Du auch die root-crontab benutzen: sudo crontab -e

    - Der Shebang fehlt im /usr/local/bin/luefterskript.sh

    - Im ersten Codeblock:

    Chmod 666 /sys/class/gpio/gpio18/value && sudo chmod 666 /sys/class/gpio/gpio18/direction

    chmod wird klein geschrieben! ;)

  • Eine Crontab und seine Jobs haben keine Umgebungsvariablen, deshalb auch kein PATH=/bin ....

    Wenn bash als Cronjob ausgeführt werden soll, braucht es einen absoluten Pfad, also /bin/bash

    -x als Option der Shell sollte ein "unknown opion -x ignored", oder so etwas ins Logfile schreiben.

    -x als Testbedingung ist hier wohl nicht beabsichtigt.

    Ein Shellscript.sh als Subshell funktioniert auch. Never change a running ...


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Ist luefterskript.sh denn ausführbar? Das siehst Du, wenn in der Ausgabe von ls -l /usr/local/bin/luefterskript.sh in der 4. Spalte ein "x" steht. Falls nicht kannst Du das mit sudo chmod u+x /usr/local/bin/luefterskript.sh ändern.

    Hallo,

    super, danke, jetzt klappt es.

    ;)

  • Ich werde es bei nächster gelegenheit mal probieren ohne sudo.

    Bisher meckert er, das ich beim speichern keine Berechtigung habe....

    chmod habe ich geändert, hätte ich auch sehen müssen, ist ja sogar farbig dargestellt....

    • Offizieller Beitrag

    Schön, dass es nun funktioniert!

    Nur am Rande: Da Du nicht auf den Shebang eingegangen bist, hier ein Link zum Verständnis: https://de.wikipedia.org/wiki/Shebang ;)

    Falls Du hier keine Fragen mehr haben solltest, dann bitte diesen Thread noch als erledigt markieren (oben "Thema bearbeiten")

  • Und mal wieder


    In Scripten, die automatisch ausgeführt werden sollen, muss IMMER der komplette Pfad zu den in den Script verwendeten Programmen bekannt sein.

    Die Systemumgebung des Benutzers, unter dessen Namen und Rechtes das Script laufen soll, stellt das nicht sicher.

    Deshalb entweder vor jedes Programm, das in dem Script aufgerufen wird, den Pfad schreiben (wird unübersichtlich), oder am Anfang des Scriptes eine passende PATH-Variable definieren, die alle Pfade bereitststellt, die in diesem Script benötigt werden.

    Computer ..... grrrrrr

  • Eine Crontab und seine Jobs haben keine Umgebungsvariablen, deshalb auch kein PATH=/bin ....

    Das stimmt so nicht: Ein cronjob hat eine sehr reduzierte Umgebung, aber nicht keine:

    Zitat von man 5 crontab

    Several environment variables are set up automatically by the cron(8) daemon. SHELL is set to /bin/sh, and LOGNAME and HOME are set from the /etc/passwd line of the crontab's owner. PATH is set to "/usr/bin:/bin". HOME, SHELL, and PATH may be overridden by settings in the crontab; LOGNAME is the user that the job is running from, and may not be changed.

  • Oder man setzt in dem ersten aufgerufene Script die fehlenden Pfade. Ich mache das z.B. in raspiBackup wie folgt:

    Code
    DEFAULT_PATHES="/usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin"
    if [[ -e /bin/grep ]]; then
       pathElements=(${PATH//:/ })
       for p in $DEFAULT_PATHES; do
          if [[ ! " ${pathElements[@]} " =~ " ${p} " ]]; then
             [[ -z $PATH ]] && PATH=$p || PATH="$p:$PATH"
          fi
       done
       export PATH="$PATH"
    fi

    Dann kann man wie gewohnt und unabhaengig ob der PATH richtig gesetzt ist ohne absolute Pfade Commands benutzen.

Jetzt mitmachen!

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