by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Hasenradball
    @hasenradball
    Außderdem ist in der Anleitung davon nix erwähnt mit dem Working directory.
    Hasenradball
    @hasenradball
    Also aktueller Eintrag in der Konfiguration für den Service lautet:
    
    [Unit]
    Description=SmartHomeNG daemon
    After=network.target
    # After=knxd.service
    # After=knxd.socket
    
    
    [Service]
    Type=forking
    ExecStart=/usr/bin/python3 /usr/local/smarthome/bin/smarthome.py
    WorkingDirectory=/usr/local/smarthome
    User=smarthome
    PIDFile=/usr/local/smarthome/var/run/smarthome.pid
    Restart=on-abort
    TimeoutStartSec=900
    
    [Install]
    WantedBy=default.target
    Die Zeilen mit knx sind bewusst auskommentiert , da ich knx nicht nutze und auch nicht installiert habe.
    Hasenradball
    @hasenradball

    @msinn ist vielleicht der Hinweis hier das Problem?

    
    smarthome@pi-smarthome1:/usr/local/smarthome/bin $ sudo systemctl status smarthome.service
    [sudo] Passwort für smarthome:
    ● smarthome.service - SmartHomeNG daemon
       Loaded: loaded (/lib/systemd/system/smarthome.service; enabled; vendor preset: enabled)
       Active: active (running) since Fri 2020-05-22 22:13:07 CEST; 2h 1min ago
      Process: 387 ExecStart=/usr/bin/python3 /usr/local/smarthome/bin/smarthome.py (code=exited, status=0/SUCCESS)
     Main PID: 458 (python3)
        Tasks: 25 (limit: 4915)
       CGroup: /system.slice/smarthome.service
               └─458 /usr/bin/python3 /usr/local/smarthome/bin/smarthome.py
    
    Mai 22 22:12:51 pi-smarthome1 systemd[1]: Starting SmartHomeNG daemon...
    Mai 22 22:13:06 pi-smarthome1 python3[387]: Daemon PID 458
    Mai 22 22:13:07 pi-smarthome1 systemd[1]: smarthome.service: Supervising process 458 which is not our child. We'll most likely not notice when it exits.
    Mai 22 22:13:07 pi-smarthome1 systemd[1]: Started SmartHomeNG daemon.
    smarthome@pi-smarthome1:/usr/local/smarthome/bin $

    Mai 22 22:13:07 pi-smarthome1 systemd[1]: smarthome.service: Supervising process 458 which is not our child. We'll most likely not notice when it exits.

    oder müsste das Working Directory so heißen: /usr/local/smarthome/bin

    msinn
    @msinn

    oder müsste das Working Directory so heißen: /usr/local/smarthome/bin

    Nein!

    Wenn Du meine Antworten gründlich gelesen hättest, hättest Du die Frage nicht gestellt.
    Hasenradball
    @hasenradball

    @msinn ich habe Deine Antworten sehr wohl gelesen, jedoch wurdert es mich schon warum trotz richtigem Eintrag als Directory
    WorkingDirectory=/usr/local/smarthome der Neustart des Core aus dem Admin Interface nicht funktioniert.

    Ist das Einrichten von SmarthomeNG als Dienst notwendig/ sinvoll?
    Oder wäre es auch genauso gut den Start von SmarthomeNG über die rc.local zu machen?

    Ich verstehe manchmal Deine Antworten wie wenn ich was falsch gemacht hätte, jedoch habe ich mich exact an die Anleitung gehalten, daher verstehe ich auch nicht ganz deine
    Antwort in der Art Wenn Du meine Antworten gründlich gelesen hättest, hättest Du die Frage nicht gestellt.

    Hasenradball
    @hasenradball
    Die Frage wäre, sollte das System auch bei eingerichtetem Dienst über das Admin Interface neu starten, oder ist es ein Problem /Bug wenn das nicht funktioniert?
    Über die Konsole funktioniert der Neustart ja wie oben erwähnt, nur bei einem Reboot des Pi's wird dann shng ja wieder als Dienst gestartet.
    Hasenradball
    @hasenradball

    @msinn Der Core Neustart über das Admin Interface funktioniert:
    a) wenn shng nicht als service gestartet wurde.

    Der Core neustart über die Konsole funktioniert:
    a) wenn shng nicht als service gestartet wurde
    b) wenn shng als service über systemd via restart getriggert wurde

    Demnach müsste es doch im Zusammenspiel mit dem Admin interface ein Problem geben.

    Morg42
    @Morg42
    Moin, ich habe ein shng, das ein (bzw. mehrere) Items per network-Plugin sendet. Kann ich das so konfigurieren, dass zyklisch auch ohne Änderung gesendet wird? ggf. enforce_updates=true und cycle? crontab?
    In der User-Doku habe ich gelesen, dass ich für Items crontabs nutzen kann, aber ich verstehe nicht, was dann mit dem Item passiert. Ich will es ja nicht neu setzen oder verändern, sondern nur das Senden per network forcieren. Geht das? Oder muss ich das network-Plugin erweitern? ;)
    Bonze255
    @Bonze255
    Denke mit cycle würde es funktionieren
    Bzw würde ich es damit probieren
    msinn
    @msinn
    Demnach müsste es doch im Zusammenspiel mit dem Admin interface ein Problem geben.
    Nein, das Admin Interface sagt smarthomeNG nur, es soll einen Prozess python3 bin/smarthome.py -r starten. Das Admin Interface selbet startet gar nichts.
    Hasenradball
    @hasenradball
    @msinn Also dann haben wir doch das Problem gefunden!
    Sind wir da core, wenn wir davon aus gehen, dass im Normalen Betrieb shng wie in der Anleidung beschrieben als Dienst im systemd eingerichtet wurde?
    Wenn shng als Dienst läuft, also status via sudo systemctl status smarthome.service und dann vom Admin Interface der Befehl python3 bin/smarthome.py -r kommt dann läuft smarthome nicht mehr unter dem systemd als Dienst!
    Genau das lässt sich in der Konsole direkt nachvollziehen.
    psilo909
    @psilo909
    Es ist halt nicht in jedem setup als dienst eingerichtet ;-)
    Morg42
    @Morg42
    Gäbe es denn Möglichkeiten, das "kompatibel" zu gestalten? Ich habe die Logik des Neustartens nicht ganz durchblickt...
    henfri
    @henfri
    Hallo
    kann ich Structs eigentlich verschachteln?
    Also, in einem Struct einen anderen verwenden?
    Falls ja: Muss ich bei der Reihenfolge in der Definition etwas beachten?
    Hasenradball
    @hasenradball

    @psilo909

    Es ist halt nicht in jedem setup als dienst eingerichtet ;-)

    Was wäre die Alternative? Nicht als Dienst einrichten und in der rc.local mit eintragen?
    Hab ich zwar schon mal gefragt, aber keine Antwort bekommen.

    bmxp
    @bmxp
    Du müßtest zunächst feststellen, ob SHNG als Process läuft, der von systemd gestartet wurde. Laut diesem Beitrag hier https://unix.stackexchange.com/questions/274545/can-i-tell-if-im-running-in-systemd sollte das festzustellen sein. Zudem mußt Du dann den systemctl restart smarthome.service ohne sudo ausführen. Dann sollte das klappen. Wenn Du es geschafft hast, freue ich mich über einen PR. @msinn kann nicht alles auf einmal machen und was er nicht nutzt, kann er auch schlecht testen ... :wink:
    Hasenradball
    @hasenradball

    @bmxp

    Du müßtest zunächst feststellen, ob SHNG als Process läuft, der von systemd gestartet wurde. Laut diesem Beitrag hier https://unix.stackexchange.com/questions/274545/can-i-tell-if-im-running-in-systemd sollte das festzustellen sein. Zudem mußt Du dann den systemctl restart smarthome.service ohne sudo ausführen. Dann sollte das klappen. Wenn Du es geschafft hast, freue ich mich über einen PR. @msinn kann nicht alles auf einmal machen und was er nicht nutzt, kann er auch schlecht testen ... :wink:

    Du meinst konkret dann um zu entscheiden was durch den Neustart Core Befehl übers Admin Inferface geschickt wird?

    bmxp
    @bmxp
    SHNG kann nur Prozesse beenden, die im User Kontext von SmartHomeNG laufen. UNd auch nur Starten was im User Kontext vom user smarthome ist. Solange also ein systemd ein sudo für den erstmaligen Start benötigt oder auch für einen Restart wird das nicht gehen.
    Ich habe da keine Resourcen für und auch nicht genügend Ahnung. Wie geschrieben: Über einen PR der funktioniert freue ich mich. Aber bitte denkt auch dran, das nicht nur Linux auf der Welt ist sondern auch Windows und BSD/MacOS X
    Hasenradball
    @hasenradball
    @bmxp dann noch eine Frage zum Verständnis wie ist dann das Hochfahren bei dem Pi-Image gelöst?
    Kannst Du das sagen?
    Vielleicht wurde ich auch falsch verstanden, ich brauch nicht unbedingt eine sofortige Lösung.
    Ich habe nur gedacht, da in der Anleitung das Einrichten als Dienst explizit beschrieben ist, dass dies üblicherweise auch so eingesetzt wird.
    Onkel Andy
    @onkelandy
    Beim Pi Image wird das gleiche Service wie in der Komplettanleitung genutzt. Bei mir funzt auch das Neustarten über das Admin Interface. Ich vermute aber fast, das liegt an meinem Monit System. Das muss ich nochmals angucken.
    Onkel Andy
    @onkelandy

    Hab jetzt mal monit deaktiviert und es funktioniert trotzdem. Das wird während des Restarts via Admintool angezeigt.

       CGroup: /system.slice/smarthome.service
               ├─ 2326 /usr/bin/python3 /usr/local/smarthome/bin/smarthome.py
               ├─10015 /bin/sh -c /usr/bin/python3 /usr/local/smarthome/bin/smarthome.py -r
               └─10016 /usr/bin/python3 /usr/local/smarthome/bin/smarthome.py -r

    Und ein paar Sekunden später wie erwartet:

       CGroup: /system.slice/smarthome.service
               └─10054 /usr/bin/python3 /usr/local/smarthome/bin/smarthome.py

    Ein Blick auf die "running since" zeigt auch, dass shng neu gestartet wurde.

    bmxp
    @bmxp
    Ist die Frage ob SHNG auf dem Pi das selber mitbekommt. @hasenradball hatte ja die Meldung
    Mai 22 22:12:51 pi-smarthome1 systemd[1]: Starting SmartHomeNG daemon...
    Mai 22 22:13:06 pi-smarthome1 python3[387]: Daemon PID 458
    Mai 22 22:13:07 pi-smarthome1 systemd[1]: smarthome.service: Supervising process 458 which is not our child. We'll most likely not notice when it exits.
    Mai 22 22:13:07 pi-smarthome1 systemd[1]: Started SmartHomeNG daemon.
    Onkel Andy
    @onkelandy
    Was mich aber noch irritiert.. Den Reverse Proxy hab ich inzwischen so hinbekommen, dass eigentlich alles korrekt angezeigt wird, also zB Status von shng. Aber, sobald ich shng neu starte, klappt das Update des Status nicht mehr. Fehlermeldung bekomme ich keine, die ich nicht auch beim Aufruf der IP:8383 bekäme.
    Sowohl /admin als auch /api leite ich recht unspektakulär für https so weiter: proxy_pass http://$server_addr:8383;und für http so proxy_pass http://$host:8383;
    Onkel Andy
    @onkelandy
    Die obere Meldung mit "Supervising process which is not our child" hatte ich bei mir schon immer. Nie losgeworden, aber es gab auch nie Probleme. Vermutlich sollte man aber einfach die PIDFile Zeile rauskicken..
    Hasenradball
    @hasenradball

    @onkelandy Hi wie kann ich denn das bei mir nachvollziehen? Welches Admin Tool ist das genau?
    Irgendetwas muss ja doch anders sein, trotz dass wir beide den Service laut Anleitung installiert haben.

    Hab jetzt mal monit deaktiviert und es funktioniert trotzdem. Das wird während des Restarts via Admintool angezeigt.

       CGroup: /system.slice/smarthome.service
               ├─ 2326 /usr/bin/python3 /usr/local/smarthome/bin/smarthome.py
               ├─10015 /bin/sh -c /usr/bin/python3 /usr/local/smarthome/bin/smarthome.py -r
               └─10016 /usr/bin/python3 /usr/local/smarthome/bin/smarthome.py -r

    Und ein paar Sekunden später wie erwartet:

       CGroup: /system.slice/smarthome.service
               └─10054 /usr/bin/python3 /usr/local/smarthome/bin/smarthome.py

    Ein Blick auf die "running since" zeigt auch, dass shng neu gestartet wurde.

    Onkel Andy
    @onkelandy
    msinn
    @msinn
    @onkelandy In dem service file fehlt aber noch das WorkingDirectory
    Onkel Andy
    @onkelandy
    Danke für den Hinweis - jetzt ist alles aktuell
    Morg42
    @Morg42
    Ich habe jetzt auch mal getestet, weil das Neustarten vom Admin-Interface bei mir nicht so richtig wollte.
    Wenn ich mit python3 bin/smarthome.py starte, funktioniert sowohl Neustart per erneutem Aufruf mit "-r" als auch über das Admin-Tool. Der neue shng ist in der Prozessliste dann mit dem Argument "-r" geführt, hat also den ursprünglichen ersetzt, das gibt auch die neue PID so her.
    Wenn ich - wie häufig - mit "-f" starte, funktioniert es nicht richtig. shng startet neu, aber mindestens das http-Plugin startet nicht neu, weil der Port noch gebunden ist - das klingt für mich danach, dass das alte shng noch nicht sauber beendet ist. Das alte shng "-f" bleibt dauerhaft aktiv, das neue "-r" beendet sich nach einer ganzen Weile (ca. eine Minute?) wieder oder bleibt in der Prozessliste aktiv, da habe ich noch keine Systematik finden können. Das Admin-Tool läuft weiter / immer noch und zeigt dauerhaft "shng wird neu gestartet" an . Insofern scheint bei Start mit "-f" das Beenden nicht zu klappen.
    Als Dienst habe ich jetzt noch nicht probiert, weil es bei mir nirgendwo als Dienst läuft. Ich starte das über ein eigenes Skript, in einer screen-Session im Hintergrund mit "-f", und wenn es beendet/crashed (heute eigentlich nicht mehr, in einer früheren Plugin-Version), sendet das Skript eine Info per Prowl und startet die komplette screen-Session einfach neu. In dem Setup passiert das gleiche wie oben, es beendet nicht richtig.
    Hasenradball
    @hasenradball
    @onkelandy ok danke für den Link des ServiceFiles, bei mir sind ein paar Zeilen weniger drin. Ich werde es mal testen.
    @Morg42 Was bedeutet der Start mit"-f"?
    Hasenradball
    @hasenradball
    @onkelandy habe es gerade mal mit deinem Servicefile getestet das Verhalten ist unverändert. Neustart aus den AdminInterface und das shng kommt nicht mehr hoch.
    psilo909
    @psilo909

    @psilo909

    Es ist halt nicht in jedem setup als dienst eingerichtet ;-)

    Was wäre die Alternative? Nicht als Dienst einrichten und in der rc.local mit eintragen?
    Hab ich zwar schon mal gefragt, aber keine Antwort bekommen.

    keine Ahnung.. Ich starte es derzeit noch manuell. Hab das mit dem Dienst im Docker Container irgendwie nicht hinbekommen

    Morg42
    @Morg42
    @hasenradball shng bleibt im Vordergrund und wird nicht zum Daemon. Es belegt die aktive Konsole.
    Hasenradball
    @hasenradball
    @onkelandy Hi eine Frage zum unterschiedlichen Verhalten bezüglich Neusart über das Admin tool?
    könnte es daran liegen dass wir unterschiedliche Pakete installiert haben?
    grafik.png
    grafik.png
    Onkel Andy
    @onkelandy
    Ne, kann ich mir nicht vorstellen. solange alles im grünen Bereich ist, außer Testsuite und Doku, dürfte es kein Thema sein.
    Hasenradball
    @hasenradball
    Dann ist das ja schon misteriös...