Python Programm per Befehl beenden

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Nachdem da wohl nichts mehr kommt: unterlass bitte solche haltlosen Unterstellungen ...:fies:

    //EDIT: Ich habe lediglich meine Meinung/meinen Eindruck als solchen geschildert. Wenn Du Dir den Schuh anziehst obwohl Du scheinbar keine Kritik verträgst, dann hast Du ein Problem ... nicht ich.

    Ich habe meiner Verwunderung Ausdruck verliehen, weil ich meine Pythonianer hier kenne. Die korrigieren Denkfehler der Fragesteller, geben Tipps auf Neuerungen, veraltete Funktionen, Styleguides und haben meines Wissens nach bisher immer sehr konstruktiv mit den TOs zusammengearbeitet.

    Umso verblüffter bin ich, wenn ich dann sehe, dass sie sich auf so eine, in meinen Augen absolut unprofessionelle Frickellösung einlassen.

    Und nach über 30 Jahren in der Software Entwicklung glaube ich das ganz gut einschätzen zu können.

    cu,

    -ds-

  • Hallo,

    Ich kann leider nicht in die Server Files schauen, wäre das mein Server, könnte ich euch auch deutlich mehr Informationen geben, kann ich aber leider nicht, da ich keinen Einblick in den Server habe und keine permissions etwas zu ändern.

    Ich kann ihn so ntzen wie er ist, oder ich kann ihn garnicjht nutzen und wenn er nicht reconnectet, oder einmal täglich restartet oder was weiß ich macht, dann kann ich daran nichts ändern.

    Ok... die Info wäre im Eingangspost vielleicht hilfreich gewesen, also das du _keinen_ Einfluss auf den Server hast. Weil: der beste Lösungsansatz ist nun mal am Server anzusetzen. Was, wie seit eben bekannt ist, dann wohl nicht geht.

    Python
    def on_disconnect3(client, userdata,rc):
        try:
            client.reconnect()
        except:
            #ist mir egal
            pass

    Funktioniert leider auch nicht!

    Das ist auch gut so, weil das echt schlecht programmiert wäre...

    Zeig' bitte nochmal den _kompletten_ relevanten Code, also auch wie du den loop startest usw.

    Gruß, noisefloor

  • Zeig' bitte nochmal den _kompletten_ relevanten Code, also auch wie du den loop startest usw.

    Hier der aktuelle Code: (habe mal alle Log-File Zeilen und den Großteil an Excetion-Handling raus geschmissen, damit es kompakter ist. Alle auskommentierten Blöcke waren nicht Zielführend, und ja, einiges davon ist nicht sauber oder nicht schön, aber probieren kostet ja nichts!)

    Das was aktuell nicht auskommentiert ist, läuft so jetzt auch! Das Programm wird abgeschossen und neu gestartet. Dass das nicht schön ist, ist mir bewusst, aber solange es nicht auf andere Weise läuft, habe ich wenigstens irgendeine Lösung.

    Server oder Host? Ich tippe da eher auf Host ...

    Da tippst du falsch, es ist ein Server, um genau zu sein, ein Linux Server (Ubuntu 17.10 falls dich das interessiert), auf dem ich leider kein einziges Zugriffsrecht habe (also nicht mal einen username und pwd um über ne SSH-Verbindung darauf zuzugreifen und mich umzuschauen.)

    Natürlich mache ich Fehler :stumm:

  • Da tippst du falsch, es ist ein Server, um genau zu sein, ein Linux Server (Ubuntu 17.10 falls dich das interessiert),D

    Da habe ich richtig getippt ... das ist der Host. Server bezeichnet den Dienst, also ftp, http, ... und scheinbar eben auch den Broker von Dir.

    //EDIT: auf diesem Rechner werden die Inhalte "gehostet", deshalb heissen die Anbieter auch Host"er" und nicht Server"er" ...

    cu,

    -ds-

  • Hallo,

    Zitat

    Hier der aktuelle Code: (habe mal alle Log-File Zeilen und den Großteil an Excetion-Handling raus geschmissen, damit es kompakter ist.

    Kein Logging - ok. Das du das gezeigte Exception Handling raus genommen hast ist ganz schlecht, weil falsches Exception Handling Fehler wegbügelt, die man sehen will.

    Ein Beispiel hast du ja in oben gezeigten Code: das nackte `try...except` in `on_disconnect` unterdrückt einen Programmierfehler - weil `client.resonnect()` gibt es nicht, es muss wohl `client.reconnect()`heißen.

    Zitat


    um genau zu sein, ein Linux Server (Ubuntu 17.10 falls dich das interessiert)

    Ubuntu 17.10 ist EOL, d.h. es bekommt keinerlei Sicherheitsupdate mehr. Keine gute Idee, das noch zu nutzen. Weder im Heimnetwerk und erst recht nicht für Server, die im Internet exponiert sind.

    Gruß, noisefloor

  • Da habe ich richtig getippt ... das ist der Host. Server bezeichnet den Dienst, also ftp, http, ... und scheinbar eben auch den Broker von Dir.

    //EDIT: auf diesem Rechner werden die Inhalte "gehostet", deshalb heissen die Anbieter auch Host"er" und nicht Server"er" ...

    Darüber könnte man jetzt streiten... ich kenne beide Begriffe für "das Gerät"

    Hier wird auch ein "Server" und kein "Host" verkauft. Aber gut möglich, dass der korrekte Begriff "Host" ist.

    Ich habe "Host" bislang immer als gerät mit IP Adresse interprettiert, da diese Definition in vielen Situationen und Beiträgen so Sinn macht.

    Aber was jetzt richtig ist, und was falsch ist, weiß ich nicht sicher. Vielleicht ist "Server" ja einfach der umgangssprachliche Begriff dafür.
    Wenn du dir deine Brötchen mit sowas verdienst, gehe ich mal davon aus, dass du da mehr Ahnung von hast als ich!

    Aber wenn ich von dem (physischen) Gerät als Server spreche, werde ich für gewöhnlich verstanden ;)

    Natürlich mache ich Fehler :stumm:

  • Es geht mir in diesem Zusammenhang darum, ob Du Einfluss/vollen Zugriff auf den Server, also die "Serveranwendung" für Deine clients hast oder nicht. Und das ist ja wohl der Fall ...

    Mit anderen Worten: Du könntest das Verhalten beim Restart protokoliieren und ggf. Anpassungen vornehmen, damit ein sauberer reconnect() seitens der clients stattfindet.

    Ja ... ich geb' Dir recht, "umgangssprachlich" ist mit Server (auch) der Rechner gemeint. Aber da hat sich vieles falsch manifestiert. Z.B. kann man keine "SMS verschicken" weil SMS für Short Message System steht, also der Dienst, der hinter dem Versenden von Kurznachrichten steckt. Die Liste liesse sich noch endlos weiterführen, aber das sprengt den Rahmen.

    Wir sind hier in einem Forum, in dem überwiegend IT- und Elektronik-Fachleute ihre Hilfe kostenlos anbieten, und da macht es durchaus Sinn die korrekten Begriffe zu verwenden (oder im Zweifelsfall eben zu erfragen) um ihnen die Arbeit zu erleichtern.

    Das hat mit recht haben, Krümelkackerei oder Belehrungen nichts zu tun. Es ist einfach notwendig und effizienter ...

    //EDIT: Letzteres war jetzt eine allgemeine Aussage und hat keinen direkten Bezug zu Dir oder Deinem Posting.

    cu,

    -ds-

  • Code
    def on_disconnect(client, userdata,rc):
        if rc !=0:
            sys.exit()

    Hast Du hier nicht schon den Fehler? rc != 0 bedeutet doch einen aus Sicht des clients unerwarteten disconnect – und in dem Fall versuchst Du erst gar keine erneute Verbindung, obwohl das ja eigentlich genau der Fall ist, den Du abhandeln möchtest.

    rc

    the disconnection result

    The rc parameter indicates the disconnection state. If MQTT_ERR_SUCCESS (0), the callback was called in response to a disconnect() call. If any other value the disconnection was unexpected, such as might be caused by a network error.

  • eben nicht wenn ich ihn richtig verstanden habe

    Hmm ... deshalb hatte ich ja nachgehakt ... für mich hat er erst mal nur den Zugriff auf den Rechner ausgeschlossen. Von der Software (Broker oder was auch immer) hat er nix geschrieben (oder ich hab's überlesen).

    Na mal sehen ... da kommt schon noch eine Klarstellung.

    cu,

    -ds-

  • Hmm ... deshalb hatte ich ja nachgehakt ... für mich hat er erst mal nur den Zugriff auf den Rechner ausgeschlossen. Von der Software (Broker oder was auch immer) hat er nix geschrieben (oder ich hab's überlesen).

    Na mal sehen ... da kommt schon noch eine Klarstellung.

    cu,

    -ds-

    ich habe keinen zugriff auf den Rechner, und demnach auch keinen Zugriff auf irgendeinen Dienst!

    Also ich kann nicht auf den Rechner zugreifen über SSH oder FTP oder was weiß ich, ich kann lediglich den Broker verwenden, aber an diesem auch keine Einstellungen vornehmen. Ich kann nur alle möglichen Einstellungen dec Clients verändern.

    Ich kann auf dem Host weder irgendwelche Einstellungen in /etc/mosquitto vornehmen, noch kann ich irgendwelche Informationen aus /var/log/syslog oder /var/log/mosquito.log auslesen.

    Könnte ich das, wäre das alles deutlich einfacher zu reparieren bzw. einfacher überhaupt den eigentlichen Fehler zu finden.


    Hast Du hier nicht schon den Fehler? rc != 0 bedeutet doch einen aus Sicht des clients unerwarteten disconnect – und in dem Fall versuchst Du erst gar keine erneute Verbindung, obwohl das ja eigentlich genau der Fall ist, den Du abhandeln möchtest.

    ein result Code ==0 wäre ja ein erwarteter dc, quasi durch client.disconnect() der ist mir egal. Mein ansatz war in diesem Fall auch wieder das Programm abzuschießen, um es neu zu starten.

    rc==0 interessiert mich nicht, das ist ja kein unerwarteter absturz (wie der Broker ist nicht mehr erreichbar)

    Aber dass Programm abschießen schlechter Stil ist hatten wir ja schon ;)

    Wäre wohl elegant! funktioniert aber eben leider nicht.

    Natürlich mache ich Fehler :stumm:

  • Ok ... schwere Geburt ...

    Wie sieht das mit der "keep alive time" aus? Welcher Wert ist da gesetzt?

    keep alive habe ich auf 60 gesetzt, über den Wert habe ich mir allerdings noch garkeine Sonderlich großen Gedanken gemacht... das ist auch der default Wert, wenn ich nichts eingebe.

    Meinst du das kann einen Fehler provozieren?

    Natürlich mache ich Fehler :stumm:

  • Ja ... kann er. Wenn der client sich nicht innerhalb der angegebenen Zeit meldet, sendet der Broker eine LWT message (falls angegeben) und schliesst die Verbindung. Stehen innerhalb des time out keine Daten zum senden an, dann muss der client einen PINGREQ schicken.

    -> https://www.hivemq.com/blog/mqtt-esse…lient-take-over

    -> https://www.hivemq.com/blog/mqtt-esse…l-and-testament

    btw: Du hattest den disconnect doch erhalten. Lediglich der exit funktionierte nicht ein print aber schon ... oder wie war das weiter vorne?

    cu,

    -ds-

  • btw: Du hattest den disconnect doch erhalten. Lediglich der exit funktionierte nicht ein print aber schon ... oder wie war das weiter vorne?

    Ja genau, das war zwar nur ein Testskript (über einen anderen, (lokalen) Host, auf dem ich mit sudo /etc/init.d/mosquitto stop bzw. start den bekannten Fehler provozieren kann. Das eigentliche Programm hat natürlich keine print befehle, es läuft im Hintergrund)

    aber innerhalb der disconnect Funktion war es auch nicht möglich über try-reconnect die verbindung wieder aufzubauen...


    Was den keepalive angeht:

    Da ich einmal pro sekunde einen Wert versende, dürfte der keepalive keine Probleme machen oder?? ich meine wenn mein PI jetzt 3 minuten lang keine Wert verschickt, würde er disconnecten, aber das problem dürfte bei einem keepalive von 60 Sekunden und einer Sekündlichen übertragung nicht auftreten, falls ich das richtig verstanden habe versteht sich...

    Natürlich mache ich Fehler :stumm:

  • Ich bin jetzt doch mal neugierig geworden und muss feststellen, daß ich das Problem nicht nachvollziehen kann. Mit diesem simplen Code:

    verbindet sich der client sauber wieder mit mosquitto, wenn ich das stoppe und wieder starte. Während mosquitto down ist, meckert er auch brav die Probleme an. Kann es sein, daß Du es Dir zu kompliziert gemacht hast?

    Nachtrag: In mosquitto kommen mit qos=1 übrigens auch tatsächlich alle veröffentlichten Nachrichten an.

    Einmal editiert, zuletzt von Manul (15. August 2018 um 17:20) aus folgendem Grund: Nachtrag ergänzt.

Jetzt mitmachen!

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