Hallo zusammen,
trotz QOS 1 oder 2 werden Nachrichten vom Broker nicht an den Client ausgeliefert wenn dieser kurz offline ist.
Müsste der Broker die Nachricht nicht speichern wenn der Client offline ist? Und wie lange eigentlich?
Danke
Hallo zusammen,
trotz QOS 1 oder 2 werden Nachrichten vom Broker nicht an den Client ausgeliefert wenn dieser kurz offline ist.
Müsste der Broker die Nachricht nicht speichern wenn der Client offline ist? Und wie lange eigentlich?
Danke
war geschäftlich unterwegs, hoffe morgen mal weiter testen zu können.
vielen Dank, ich arbeite dann mal alle Infos von euch durch und melde mich wieder.
Nicht so leicht alles, aber man lernt wenigstens viel dazu, beim Fehler suchen
Jetzt wird es immer blöder (war schon vor deinen Empfehlungen mit den Unit-Änderungen so) dass auch der manuelle Start nicht mehr klappt:
\u25cf k40_rl.service - k40_rl
Loaded: loaded (/etc/systemd/system/k40_rl.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2021-09-08 21:48:40 CEST; 10s ago
Process: 1017 ExecStart=/usr/bin/python3 -u k40_rl_automatik.py (code=exited, status=200/CHDIR)
Main PID: 1017 (code=exited, status=200/CHDIR)
Sep 08 21:48:40 raspberrypi systemd[1]: k40_rl.service: Service RestartSec=100ms expired, scheduling restart.
Sep 08 21:48:40 raspberrypi systemd[1]: k40_rl.service: Scheduled restart job, restart counter is at 5.
Sep 08 21:48:40 raspberrypi systemd[1]: Stopped k40_rl.
Sep 08 21:48:40 raspberrypi systemd[1]: k40_rl.service: Start request repeated too quickly.
Sep 08 21:48:40 raspberrypi systemd[1]: k40_rl.service: Failed with result 'exit-code'.
Sep 08 21:48:40 raspberrypi systemd[1]: Failed to start k40_rl.
mit:
[Unit]
Description=k40_rl
After=network-online.target
Wants=network-online.target
[Service]
ExecStart=/usr/bin/python3 -u k40_rl_automatik.py
WorkingDirectory=/home/pi/prod3/k40
StandardOutput=inherit
StandardError=inherit
Restart=always
User=pi
[Install]
WantedBy=multi-user.target
Hab jetzt auch mal in meiner Not ein Raspi-Update gemacht.
Pythonprogramm k40_rl_automatik.py funktioniert wenigstens noch wenn man es direkt im Thonny ablaufen lässt. Wollte aber schon, dass es automatisch hochfährt wenn mal Stromausfall wäre und der Raspi neu hoch fährt. Vielleicht kommt ja noch ein Tipp von Euch.
Danke
wobei Mosquitto doch vorher geladen wird
Anbei die zwei Status zu meinem Service und den von Mosquitto.
Was meint ihr? Wird jetzt zu komplex für mich!
\u25cf k40_rl.service - k40_rl
Loaded: loaded (/etc/systemd/system/k40_rl.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2021-09-08 19:46:18 CEST; 41s ago
Process: 392 ExecStart=/home/pi/prodr3/k40/k40_rl_automatik.py (code=exited, status=1/FAILURE)
Main PID: 392 (code=exited, status=1/FAILURE)
Sep 08 19:46:18 raspberrypi k40_rl_automatik.py[392]: return self.reconnect()
Sep 08 19:46:18 raspberrypi k40_rl_automatik.py[392]: File "/usr/lib/python3/dist-packages/paho/mqtt/client.py", line 962, in reconnect
Sep 08 19:46:18 raspberrypi k40_rl_automatik.py[392]: sock = socket.create_connection((self._host, self._port), source_address=(self._bind_
Sep 08 19:46:18 raspberrypi k40_rl_automatik.py[392]: File "/usr/lib/python3.7/socket.py", line 727, in create_connection
Sep 08 19:46:18 raspberrypi k40_rl_automatik.py[392]: raise err
Sep 08 19:46:18 raspberrypi k40_rl_automatik.py[392]: File "/usr/lib/python3.7/socket.py", line 716, in create_connection
Sep 08 19:46:18 raspberrypi k40_rl_automatik.py[392]: sock.connect(sa)
Sep 08 19:46:18 raspberrypi k40_rl_automatik.py[392]: OSError: [Errno 101] Network is unreachable
Sep 08 19:46:18 raspberrypi systemd[1]: k40_rl.service: Main process exited, code=exited, status=1/FAILURE
Sep 08 19:46:18 raspberrypi systemd[1]: k40_rl.service: Failed with result 'exit-code'.
pi@raspberrypi:~ $ sudo systemctl status mosquitto.service
\u25cf mosquitto.service - Mosquitto MQTT v3.1/v3.1.1 Broker
Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2021-09-08 19:46:17 CEST; 1min 2s ago
Docs: man:mosquitto.conf(5)
man:mosquitto(8)
Main PID: 485 (mosquitto)
Tasks: 1 (limit: 2059)
CGroup: /system.slice/mosquitto.service
\u2514\u2500485 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf
Sep 08 19:46:16 raspberrypi systemd[1]: Starting Mosquitto MQTT v3.1/v3.1.1 Broker...
Sep 08 19:46:17 raspberrypi systemd[1]: Started Mosquitto MQTT v3.1/v3.1.1 Broker.
Display More
Ja, danke
Habe den Fehler jetzt eingekreist. Wenn das vom Service gestartete Python-Programm einfacher Natur ist (mit Bash-Aufruf) so startet der Dienst fehlerfrei. Sobald das Programm komplizierter wird (ich vermute das es die MQTT-Funktionalität ist) so bricht der Dienst ab. Da das nur nach reboot ist und bei manuellem Start nicht, vermute ich, dass MQTT noch nicht "wachgeküsst" ist. Weitere Funktionalitäten außer Bash-Aufruf und MQTT gibt es im Programm nicht. Es muss also der Mosquitto-Service sein der noch nicht geladen ist.
Bin am kämpfen und habe jetzt so folgendem Service (vereinfacht wie oben vorgeschlagen):
[Unit]
Description=k40_rl
[Service]
ExecStart=home/pi/prodr3/k40/k40_rl_automatik.py
[Install]
WantedBy=multi-user.target
....folgende Meldung bekommen
\u25cf k40_rl.service - k40_rl
Loaded: bad-setting (Reason: Unit k40_rl.service has a bad unit file setting.)
Active: inactive (dead)
Was sind bad unit file settings?
Hallo,
habe jetzt einen Dienst mit Dauerschleife aufgebaut.
[Unit]
Description=Mein service_test
[Service]
ExecStart=/home/pi/prodr3/jobs/service_test.py
[Install]
WantedBy=multi-user.target
#!/usr/bin/python3
import sys, time
import subprocess #bash starten
while True:
lt = time.localtime()
Stunde,Minute = lt[3:5]
if Stunde == 14 and Minute == 55:
bashreturn = subprocess.call('./hoch.bash')
time.sleep(40)
time.sleep(40)
Display More
und er läuft:
pi@raspberrypi:/etc/systemd/system $ systemctl status service_test
\u25cf service_test.service - Mein service_test
Loaded: loaded (/etc/systemd/system/service_test.service; enabled; vendor pre
Active: active (running) since Wed 2021-09-08 17:53:31 CEST; 8min ago
Main PID: 413 (service_test.py)
Tasks: 1 (limit: 2059)
CGroup: /system.slice/service_test.service
\u2514\u2500413 /usr/bin/python3 /home/pi/prodr3/jobs/service_test.py
Jetzt gehe ich nochmals an die ursprünglich nicht laufenden Jobs. Kann es sein, dass das umbenennen der Services ein Fehler war der irgendwie anders wieder gerade gebogen werden muss? In den zugehörigen Python-Programmen wird auf MQTT zugegriffen und es werden bash-Skripte ausgeführt. Das war aber alles gar kein Problem bis zum umbenennen der Services.
Diesen Dienst habe ich gestern erstellt und er funktioniert:
[Unit]
Description=r3b_blink
After=network.target
[Service]
ExecStart=/usr/bin/python3 -u on_blink.py
WorkingDirectory=/home/pi/prodr3/jobs
StandardOutput=inherit
StandardError=inherit
Restart=always
User=pi
[Install]
WantedBy=multi-user.target
Quellcode zu: home/pi/prodr3/jobs/on_blink.py
Das spricht für mismatch von Zeichensätzen. Normalerweise ist das ein Listenpunkt / schwarzer Punt im Unicode
Der Punkt ist in der Terminaldarstellung von systemctl status ..... ein grüner Punkt. Siehe hier Protokoll eines funktionierenden Dienstes:
systemctl status r3b_blink
\u25cf r3b_blink.service - r3b_blink
Loaded: loaded (/etc/systemd/system/r3b_blink.service; enabled; vendor preset
Active: active (running) since Wed 2021-09-08 16:52:55 CEST; 14min ago
Main PID: 482 (python3)
Tasks: 1 (limit: 2059)
CGroup: /system.slice/r3b_blink.service
\u2514\u2500482 /usr/bin/python3 -u on_blink.py
Sep 08 16:52:55 raspberrypi systemd[1]: Started r3b_blink.
Jetzt zum Testvorschlag von Dennis 89
Jetzt sollte in /home/pi/ eine Datei test.txt erstellt worden sein.
... eine /home/pi/test.txt hat er NICHT erstellt.
pi@raspberrypi:~ $ systemctl status servicename.service
\u25cf servicename.service - Do something
Loaded: loaded (/etc/systemd/system/servicename.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Wed 2021-09-08 16:52:56 CEST; 6min ago
Process: 374 ExecStart=/home/pi/programmtest.py (code=exited, status=0/SUCCESS)
Main PID: 374 (code=exited, status=0/SUCCESS)
Sep 08 16:52:54 raspberrypi systemd[1]: Started Do something.
Sep 08 16:52:56 raspberrypi systemd[1]: servicename.service: Succeeded.
meine Servicedatei hierzu:
[Unit]
Description=Do something
[Service]
ExecStart=/home/pi/programmtest.py
[Install]
WantedBy=multi-user.target
Servis natürlich enabled
Programm per copy/paste in Datei programmtest.py übertragen
chmod +x hatte ich gemacht
Servicedatei:
[Unit]
Description=k41_rl
After=network.target
[Service]
ExecStart=/usr/bin/python3 -u k41_rl_automatik.py
WorkingDirectory=/home/pi/prodr3/k41
StandardOutput=inherit
StandardError=inherit
Restart=always
User=pi
[Install]
WantedBy=multi-user.target
Inhalt k41_rl_automatik.py:
#!/usr/bin/python3
print("hello")
... wie gesagt, läuft nur nicht mit einem reboot. Manueller Start des Dienstes funktioniert.
Hallo,
konnte erst heute bischen weiter testen aber hoffe mit folgenden Tests eure Fragen zu beantworten:
1.) Das was aufgerufen wird ist eine Python-Programm. Habe den Inhalt jetzt vereinfacht und nur mit print("Hello world") bestückt und trotzdem bricht der Ladeprozess ab. Also am Inhalt des Programmes kann es nicht liegen.
2.) Habe einen neuen Service aufgebaut mit dem gleichen Inhalt und den gleichen Berechtigungen wie die anderen Service nur mit dem Start eines einfachen Python Programmes welches eine LED blinken lässt, und das hat er geladen. Also müssen auch die Service-Dateien sauber sein.
Ganz komisch alles. Ich schau mir nochmal alles Buchstabe für Buchstabe an.
Hallo,
der führende Unterstrich ist mir beim Reinkopiern hier reingerutscht
sudo systemctl status _rl_automatik_sommer.service
Das mit dem disablen des alten Prozesses bin ich mir nicht sicher, aber glaube schon.
In der neuen Servicedatei habe ich eine Namensänderung bei der Python-Datei vorgenommen.
Heute abend schaue ich mir das nochmals anhand eurer Tipps an.
Danke bisher
Hallo Zusammen,
nachdem ich eine meiner Service-Dateien umbenannt habe, bricht der Dienst beim booten des Raspi ab. Wenn ich den Dienst manuell starte (sudo systemctl start ....) klappt es aber, womit ich ausschließe, dass die Dienstedatei fehlerhaft ist. Dienst ist enable und daemon-reload habe ich auch schon gemacht. Welche Berechtigung muss Service-Datei haben? Wo bekomme ich mehr Informationen über den Grund des Abbruches?
sudo systemctl status _rl_automatik_sommer.service
\u25cf rl_automatik_sommer.service - rl_sommer
Loaded: loaded (/etc/systemd/system/rl_automatik_sommer.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2021-09-05 22:24:10 CEST; 1min 18s ago
Process: 575 ExecStart=/usr/bin/python3 -u rl_automatik_sommer.py (code=exited, status=1/FAILURE)
Main PID: 575 (code=exited, status=1/FAILURE)
Vielen Danke
Euch allen vielen Dank.
Ohne mich schon eingelesen zu haben (danke für die Links), denke ich, dass ich mit systemd auch bestimmen kann, welcher Prozess unbedingt vorher gelaufen sein muss (After) - das kommt mir sehr entgegen. Danke aber auch die Korrekturinfo zu rc.lokal.
Was macht das Restart=always?
Hallo noisefloor,
ja, steht auch in meinem Raspi-Buch das rc.local ein altes Relikt ist - wollte mir es halt schnell und einfach machen. Aber du hast Recht, ich mach was "gescheites" und schau mir systemd an.
Die prints sind drin weil ich das Script auch manchmal in der Konsole laufen lasse.
Danke und Gruß
Es läuft!
Die Option "-z" muss ganz weg und der Parameter in SCRIPT sollte in Gänsefüsschen stehen.
Irgendwie läuft es bei mir nicht, die Jobs (PID's) werden nicht gefunden.