Beiträge von rhobin

    D. h. Du willst die Ausgabe von:

    Code
    bash -x /home/pi/mqtt/mqtt1.sh

    nicht posten?

    Du hast mich bzgl. "aber nicht "/usr/bin/bash"", noch nicht überzeugt. Was ist daran so schwer, die Ausgabe von:

    Code
    file /usr/bin/bash

    hier zu posten?

    Meine Güte, sei doch nicht so empfindlich. Ich hab' doch gar nicht gesagt, dass ich das nicht posten will, ich hab' mich gestern nur abgemeldet, weil ich auch noch ein Leben neben dem Computer habe.

    bash - x.... bringt:

    /usr/bin/mosquitto_sub -h 127.0.0.1 -v -C 1 -t /rpi/total -t inverter/total/P_AC

    und file /usr/bin/bash bringt:

    /usr/bin/bash: cannot open `/usr/bin/bash' (No such file or directory)

    Das hatte ich Dir ja schon früher geschrieben, der "bash"-Befehl liegt bei mir in "/bin" und nicht in "/usr/bin/". Warum glaubst Du mir das nicht?

    und "file/bin/bash" bringt die gleiche Antwort wie bei User "hyle" - wie auch seine anderen Abfragen.

    Was mich nicht wundert, weil "Buster" ist dann wohl doch gleich "Buster"

    Also für mich ist das Thema erledigt. Ich danke allen für ihre Hilfe.

    Gruß

    Rhobin

    Dann poste mal mit der bash in der shebang, die Ausgaben von:

    Code
    bash -x /home/pi/mqtt/mqtt1.sh

    Wie hast Du festgestellt, dass das Verzeichnis "/usr/bin" nicht existiert? "/usr/bin/bash" ist eine Datei (binary). Siehe z. B. die Ausgaben von:

    Code
    file /usr/bin/
    file /usr/bin/bash
    file /bin/bash

    auf deinem PI mit buster.

    Der Bash_Befehl bringt:

    + /usr/bin/mosquitto_sub -h 127.0.0.1 -v -C 1 -t /rpi/total -t inverter/total/P_AC

    dir Mosquitto-Befehl steht tatsächlich in "/usr/bin"

    Da habe ich mich missverständlich ausgedrückt. Das Verzeichnis "/usr/bin/" existiert, aber nicht "/usr/bin/bash". Der Bash-Befehl steht in "/bin"

    Melde mich für heute ab! Danke!

    Oder evtl. die shebang deines Scriptes? Verwende mal als shebang im Script für die Ausführung via crontab:

    Bash
    #!/bin/sh           # oder /usr/bin/sh

    und für die (manuelle) Ausführung des Scriptes in/mit der Kommandozeile:

    Bash
    #!/bin/bash

    ich habe für die manuelle Ausführung "#!/usr/bin/bash" eingegeben und erhalte folgende Antwort

    "/usr/sbin/mosquitto_sub: Datei oder Verzeichnis nicht gefunden"

    Witzigerweise lautet der Befehl im Skript "/usr/bin/mosquitto..." und nicht "/usr/sbin/..." Skript wird zwar ausgeführt, aber passieren tut nix - wie uch bei der Fehler-Meldung

    "#!/usr/bin/bash" über crontab kann nicht funktionieren, weil dieses Verzeichnis nicht existiert - weiß der Geier warum.

    Und funktioniert auch nicht!

    Was sind bei Dir die Ausgaben von

    Code
    uname -r
    cat /etc/os-release

    ?

    5.10.63-v7l+

    +

    PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"

    NAME="Raspbian GNU/Linux"

    VERSION_ID="10"

    VERSION="10 (buster)"

    VERSION_CODENAME=buster

    ID=raspbian

    ID_LIKE=debian

    HOME_URL="http://www.raspbian.org/"

    SUPPORT_URL="http://www.raspbian.org/RaspbianForums"

    BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

    Die Crontabs haben default dash als Shell, das CLI verwendet bash bei den Raspberry Pi OS.

    Edit

    Die "which"-Abfragen weisen bei mir alle auf "/bin/****". Die Verzeichnisse "/usr/bin/bash" und die von "dash" und "sh" gibt es nicht.

    BTW: Das war bzw. ist keine Unterstellung (von Ahnungslosigkeit). Es geht um "technische Fakten", d. h. was bekannt ist bzw. was nicht bekannt ist. Du kannst _nur_ das schreiben bzw. mitteilen, was Du auch weißt.

    OK, jetzt funktioniert es (anscheinend), aber wir wissen nicht was die Ursache war, weil es vorher nicht funktioniert hat, oder?

    OK! Akzeptiert!

    Und ja: Wir wissen jetzt nicht genau, woran es lag. Es hat was mit dem "env" zu tun - denn die Ausgabe auf der Konsole und aus der crontab sind sehr unterschiedlich. Können die Pfade etwas damit zu tun haben?

    Konsole:

    PATH=/home/pi/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games

    crontab:

    PATH=/usr/bin:/bin

    Hm, ... weil der TE "5 min später" geschrieben hat? Meinst Du jetzt 5 Minuten nach dem booten? Der TE hat etwas geändert, schreibt aber nicht genau, was er geändert hat (... weil er es nicht weiß bzw. weil er nicht weiß, was die "Änderung" bewirkt hat ...)?

    5 min später meint, dass ich erst 5min später bemerkt habe, dass der mqtt-Job aus der crontab läuft - ich starre nicht jede Sekunde auf die herausgeschriebenen Dateien.

    Ich hab Dir doch geschrieben, dass ich nichts in der crontag geändert habe, außer "usr/bin/date" zu "/bin/date".

    Du musst schon genau lesen, bevor Du mir mit "...er nicht weiß, was..." Ahnungslosigkeit unterstellt.

    Ist aber auch egal , es läuft jetzt also Danke für die Hilfe - besonders an "llutz"

    Vergleiche mal die Ausgabe von "env" aus der Kommandozeile mit der aus der user-crontab:

    Code
    env > /tmp/envcl.output
    Code
    * *    * * *    /usr/bin/env > /tmp/envcr.output

    danach in der user-crontab:

    Code
    # * *    * * *    /usr/bin/env > /tmp/envcr.output

    und vergleichen:

    Code
    diff /tmp/envcr.output /tmp/envcl.output

    Evtl. hast Du mit den Änderungen/Testen von /bin/date zu /usr/bin/date, bzgl. env, in der crontab etwas (temporär?) geändert

    Oha! Da sind gewaltige Unterschiede! Ich kopiere mal nur die Ausgabe, die aus der crontab geschrieben wurde (Sonst wird das zu lang - auch die Ausgabe von "diff"):

    HOME=/home/pi

    MAILTO=

    LOGNAME=pi

    PATH=/usr/bin:/bin

    LANG=de_DE

    SHELL=/bin/sh

    PWD=/home/pi

    Der env-Befehl aus der Konsole liefert mehr als doppelt soviele Zeilen mit einem ewig langen "Colors"-Zweig und zahlreiche anderen Informationen wie "SSH_Connection" oder einem wesentlich längeren "PATH"...

    Nee an der crontab hatte ich zwischen "geht und geht nicht" garantiert nix verändert ausser der Eingabe von "date".

    Naja, Du solltest uns sagen welches OS Du benutzt, denn mit bullseye und der user-crontab geht auch das:

    Code
    * *    * * *    /usr/bin/date >>/tmp/crontest1
    * *     * * *   /bin/date >>/tmp/crontest2
    # ---

    =>:

    Code
    :~ $ cat /tmp/crontest1 && cat /tmp/crontest2
    Sat  4 Mar 09:38:01 CET 2023
    Sat  4 Mar 09:39:01 CET 2023
    Sat  4 Mar 09:40:01 CET 2023
    Sat  4 Mar 09:38:01 CET 2023
    Sat  4 Mar 09:39:01 CET 2023
    Sat  4 Mar 09:40:01 CET 2023

    Raspbian GNU/Linux 10 (buster)

    Checke mal den Pfad type date, evtl. ist es /bin/date

    Yep! Funktioniert!

    In crontest steht jetzt das Datum!

    Heißt also, die mqtt1.sh wird ausgefürt, nur scheinbar der mosquitto-Befehl nicht - auch nicht mit Angabe der absoluten Pfade. Sehr seltsam!

    EDIT: 5 min später: Jetzt läuft das Skript problemlos durch. Seit einfügen des /bin/date-Befehles scheint auch der mosquitto-Befehl zu funktionieren! :)

    Muss ich das verstehen? :denker:

    journalctl -u cron.service -n 20 --no-pager sagt was?

    -- Logs begin at Tue 2023-02-28 17:17:01 CET, end at Fri 2023-03-03 17:12:06 CET. --

    M▒r 03 17:10:01 raspberrypi4 CRON[22578]: pam_unix(cron:session): session closed for user pi

    M▒r 03 17:10:06 raspberrypi4 CRON[22576]: pam_unix(cron:session): session closed for user pi

    M▒r 03 17:11:01 raspberrypi4 CRON[22643]: pam_unix(cron:session): session opened for user pi by (uid=0)

    M▒r 03 17:11:01 raspberrypi4 CRON[22644]: pam_unix(cron:session): session opened for user pi by (uid=0)

    M▒r 03 17:11:01 raspberrypi4 CRON[22645]: (pi) CMD (python3 /home/pi/mqtt/mqtt1.py >> /home/pi/mqtt/mqtt_log.log 2>&1)

    M▒r 03 17:11:01 raspberrypi4 CRON[22646]: (pi) CMD (/home/pi/mqtt/mqtt1.sh >> /home/pi/mqtt/mqtt_log.log 2>&1)

    M▒r 03 17:11:01 raspberrypi4 sudo[22652]: pam_unix(sudo:session): session opened for user root by (uid=0)

    M▒r 03 17:11:01 raspberrypi4 sudo[22652]: pam_unix(sudo:session): session closed for user root

    M▒r 03 17:11:01 raspberrypi4 CRON[22644]: pam_unix(cron:session): session closed for user pi

    M▒r 03 17:11:06 raspberrypi4 CRON[22643]: pam_unix(cron:session): session closed for user pi

    M▒r 03 17:12:01 raspberrypi4 CRON[22698]: pam_unix(cron:session): session opened for user pi by (uid=0)

    M▒r 03 17:12:01 raspberrypi4 CRON[22699]: pam_unix(cron:session): session opened for user pi by (uid=0)

    M▒r 03 17:12:01 raspberrypi4 CRON[22700]: (pi) CMD (python3 /home/pi/mqtt/mqtt1.py >> /home/pi/mqtt/mqtt_log.log 2>&1)

    M▒r 03 17:12:01 raspberrypi4 CRON[22701]: (pi) CMD (/home/pi/mqtt/mqtt1.sh >> /home/pi/mqtt/mqtt_log.log 2>&1)

    M▒r 03 17:12:01 raspberrypi4 sudo[22707]: pam_unix(sudo:session): session opened for user root by (uid=0)

    M▒r 03 17:12:01 raspberrypi4 sudo[22707]: pam_unix(sudo:session): session closed for user root

    M▒r 03 17:12:01 raspberrypi4 CRON[22699]: pam_unix(cron:session): session closed for user pi

    M▒r 03 17:12:06 raspberrypi4 CRON[22698]: pam_unix(cron:session): session closed for user pi

    Hi Leute,

    ich weiß, dass das Thema schon mehrfach angesprochen wurde, ich habe mehrere 100 Treffen in der Suche nach "crontab" bekommen und wollte die alten Threads nicht wieder aufmachen....

    Folgender Befeh in der crontab...

    * * * * * bash /home/pi/mqtt/mqtt1.sh >> /home/pi/mqtt/mqtt.log 2>&1

    ...soll das Skript "mqtt1.sh" aufrufen...tut es aber nicht. Ein "return" steht natürlich auch hinter der Zeile.

    Manuell klappt das mit und ohne den Vorsatz "bash" ohne weiteres - der Shebang ist also offensichtlich korrekt.

    Freue mich über eure Kommentare :)

    Gruß Rhobin

    Hi noiseflor,

    danke für den Link - über github habe ich heute bereits das Projekt entdeckt. Leider geht es dabei mehr um die Verbindung von Raspi und Arduio via NRF24.

    Ich stehe jetzt vor dem Problem, dass der Pi und der NRF laufen, allerdings verlangt das Programm eine 3-5stellige Client-Adresse, die ich von der Inverter leider nicht habe (der wird über eine 12stellige Seriennummer des INverters angesprochen. Da muss ich wohl den entwickler selbst mal ansprechen.

    Gruß

    Rhobin