Das deutsche Python-Forum

Hallo,

mein Python skript beginnt durch eine while schleife immer wieder von vorne und soll so 24stunden am Tag durchgehend laufen.
Aufbau ungefähr so:
while 1
printe uhrzeit
mache api calls
rechne damit ein wenig und printe ergebnisse
mache weitere api calls
rechen damit und printe ergebnisse


Nun gibt es 2 Probleme, die vermutlich durch den Raspberry Pi bedingt sind, auf dem das Skript läuft. (es ist Pi1 Model B 512MB mit WLAN USB Adapter).

1. Wenn ich das Skript auf dem Laptop mit WLAN in der shell laufen habe, dauert ein schleifendurchlauf zwischen 3-5 sekunden (je nach dem, wie lange die API Calls brauchen, das variiert so ein bisschen). Wenn ich es aber auf dem Pi laufen habe, braucht ein Durchlauf schon 4-7 sekunden. Das ist schon ein erheblicher Unterschied... ich würde das gerne verschnellern.

2. Ca. alle 36 Stunden (grob, manchmal auch schon früher, manchmal später) friert die Ausführung des Skriptes sozusagen ein. Er printet noch die Uhrzeit, was er beim Start jedes Schleifendurchgangs tut, aber danach ist schluss. Eigentlich sollte er nun noch ein paar API Calls machen, das Ergebnis printen, noch ein paar Calls und wieder das Ergebnis printen. Er tut es aber nicht. Das LXTerminal bleibt einfach so stehen. Ich kann zwar noch alles klicken, es ist also kein "aufhängen" des Pi. Er führt nur einfach das Skript nicht mehr weiter aus. Er bleibt im Skript stecken, es beendet sich also nicht... und morgens kann ich dann im terminal ablesen, dass er mal wieder um 3 uhr nachts "verreckt" ist...
Ich habe jeden API Call in einem try Block, dh. wenn ein Fehler auftreten sollte, sollte dieser in einer txtdatei vermerkt werden. Da steht aber nichts drin. Auch habe ich zusätzlich die ganze Schleife in einen try block gepackt (das habe ich erst seit kurzem so, das einfrieren gab es aber auch schon vorher), damit auch sonstige Skriptfehler in die txtdatei geschrieben werden und ich sie später nachlesen kann.
Daraus und weil das skript schließlich viele stunden problemlos läuft, schließe ich mal, dass kein Fehler auftritt.
(hier ist das einzige was mir einfällt, dass er eine Anfrage an die API sendet, aber keine Antwort erhält. nun wartet der Bot ewig und drei tage auf die antwort und macht so lange nicht weiter. Ich gehe aber mal davon aus, dass es im request modul dafür einen Fehler gibt, der nach einer Zeit x dann ausgegeben wird, oder? Falls es so eine Fehlermeldung nicht gibt, wie könnte ich dann rausfinden, ob das die ursache ist?)

Auf meinem Laptop habe ich das Skript noch nicht 36 Stunden am Stück laufen gehabt, aber immerhin 6 Stunden ohne Probleme. Als das Skript noch deutlich weniger umfangreich war und ich noch keinen Pi hatte, lief es am TowerPC für 48stunden, ohne einzufrieren. Als ich kurz danach den Pi kaufte und nutzte, frierte es schon damals ab und an (ca. alle 72 stunden) ein. Ich würde behaupten, dass es häufiger wird... was vllt daran liegt, dass das Skript immer umfangreicher wird?

Jedenfalls stellen sich mir jetzt die Fragen:
- Warum dauert ein Durchlauf länger als am Laptop?
- Warum friert der Durchlauf ein, was könnte es da für Ursachen geben?
- Der Pi wird ja bei vielen Menschen 24h/am tag eingesetzt, passiert das Einfrieren bei denen/euch auch?
- Könnten beide Probleme mit der Leisungsfähigkeit des Pi begründet werden?
- Wäre es dann also eine Lösung den neuen Pi2 zu kaufen und zu nutzen? Oder wird es bei diesem dasselbe Problem geben?
- Was kann ich tun, um rauszufinden, wo das Problem liegt und ob es der Pi2 lösen würde?

Serpens66

@Serpens66: mit den Informationen, die Du gegeben hast, kann man gar nichts sagen. Natürlich ist ein PI langsamer als ein Laptop. Ob das jetzt 1 oder 2 Sekunden sind, hängt halt davon ab, was Du machst, und ob 7 Sekunden viel oder wenig sind, erst recht. "Einfrieren" sagt ja soviel wie "da kommt kein Fehler", weshalb ich mich nicht wundere, dass Deine Versuche, den Fehler zu finden, nichts gebracht haben.
Zeig doch einfach mal das Programm, dann kann man da schon mehr sagen.

Sirius3 hat geschrieben:@Serpens66: mit den Informationen, die Du gegeben hast, kann man gar nichts sagen. Natürlich ist ein PI langsamer als ein Laptop. Ob das jetzt 1 oder 2 Sekunden sind, hängt halt davon ab, was Du machst, und ob 7 Sekunden viel oder wenig sind, erst recht. "Einfrieren" sagt ja soviel wie "da kommt kein Fehler", weshalb ich mich nicht wundere, dass Deine Versuche, den Fehler zu finden, nichts gebracht haben.
Zeig doch einfach mal das Programm, dann kann man da schon mehr sagen.

leider kann ich das Skript nicht zeigen... 1. sind es mittlerweile 3000 Zeilen. 2. ist es ein vertraulicher Code der nicht öffentlich sein darf, 3.Gehe ich davon aus, dass es nichts mit dem Code an sich zu tun hat, da es auf dem Pc bisher einwandfrei gelaufen ist und 4. ist dieser natürlich "grottenschlecht" programmiert, sodass wir noch jahrhunderte damit beschäftigt wären, jede kleine Stelle, die unschön programmiert ist zu verbessern... anstatt dem eigentlichem Problem auf die Schliche zu kommen.

was ich machen könnte, wäre das ganze Skript runterbrechen auf die ersten API Calls, wo es also immer steckenbleibt (und nach jedem einzelnen erfolgreichen Call etwas in der txt datei schreiben, damit ich sehe, ob es schon beim ersten, oder erst beim zweiten Call abbricht). Dies könnte ich dann nebenbei mitlaufen lassen und nach einiger Zeit sehen, ob auch dieses Skript einfriert. Wenn es das tut, kann ich diesen Teil des Skriptes hier posten. Werde das mal heute starten und dann hier Rückmeldung darüber geben.

Hätte ja sein können, dass auch das Einfrieren ganz normal oder ein sehr häufiges Problem ist. Dann hätte es auch ohne Skripteinblicke Lösungen gegeben

@Serpens66: Was das Einfrieren angeht müsstest Du halt möglichst genau eingrenzen wo das hängt. Wenn API-Calls hier Anfragen über das Netzwerk meinen, dann kann das zum Beispiel in der Tat auf eine Antwort warten. Nur davon auszugehen das da eine Zeitüberschreitung ausgelöst wird, reicht vielleicht nicht, das sollte ja dokumentiert sein, oder notfalls muss man den Bibliothekscode halt mit in die Fehlersuche einbeziehen.

Eventuell ist es auch ein Hardwareproblem? Ich habe einen Wifi-USB-Stick der am Raspi zum Beispiel nach ca. einem Tag Betrieb einfach nicht mehr existiert. Abziehen und wieder Anstecken ist das einzige was hilft bei dem Modell.

Wenn der Pi selber einfriert ist das bei mir immer ein Wärmeproblem gewesen. Da half kein Gehäuse zu verwenden und den so aufstellen das die Wärme sich nicht gestaut hat und nicht zu Übertakten.

Ein anderer Grund der den Raspi total in die Knie zwingt ist wenn der Speicher knapp wird und man eine Auslagerungsdatei auf SD-Karte hat.

So grundsätzlich passiert mir das Einfrieren beim Pi nicht. Ich habe einen mit RasBMC als Fernseherersatz 27/7 zu laufen. Da sind auch ein paar Skripte drauf die regelmässig Infos aus dem Netz holen und verarbeiten, OwnCloud, und ein paar private Mercurial-Repositories. Einen zweiten habe ich als „Internetradiowecker” im Betrieb. Und in der Firma haben wir etliche zu Monitoringzwecken und ein paar auch als VPN-Endpoints bei Kunden im Dauereinsatz. Da gab es bisher wenig Probleme und die waren eigentlich immer wegen Wärme. Also an eine Stelle in einem Serverrack die von sich aus schon so um die 35-40° Warm ist, sollte man das Gerät nicht aufstellen.

Der Pi 2 ist zwar schneller, aber natürlich immer noch langsamer als ein ausgewachsener Laptop. Beim 2er hätte man einen Vorteil gegenüber dem 1er wenn sich das Problem ausreichend paralellisieren lässt. Der hat ja vier Prozessorkerne. Ansonsten schafft man sich Raspis ja auch eher an weil sie wenig kosten, wenig Strom verbrauchen, und leise sind, und nicht weil man damit schnell grosse Datenmengen verarbeiten kann.

Was Geschwindigkeit und Speicherverbrauch angeht hilft es vielleicht keine grafische Oberfläche auf dem Raspi laufen zu lassen. Dann kann man vielleicht auch mehr RAM dem Betriebssystem zuweisen statt der ”Grafikkarte”. Wunder darf man da allerdings nicht erwarten.

Serpens66 hat geschrieben:...ist dieser natürlich "grottenschlecht" programmiert, sodass wir noch jahrhunderte damit beschäftigt wären, jede kleine Stelle, die unschön programmiert ist zu verbessern... anstatt dem eigentlichem Problem auf die Schliche zu kommen.

Du scheinst - wie der Chef einer Firma, wo ich mal angestellt war (die es übrigens nicht mehr gibt ) - zu glauben, dass Schönheit ein Luxus ist, den man nachträglich in ein Programm einbaut, damit es zusätzlich zu dem, wie es funktioniert, auch noch schön ist.
Code ist aber umso schöner, je klarer er zum Ausdruck bringt, was er tut. Und je weniger er das tut, umso unschöner ist er. Wenn es nicht offensichtlich ist, was dein Programm macht, dann kannst du auch nicht sehen, ob es macht, was es soll. Und wenn du das nicht sehen kannst, dann weißt du auch nicht, ob es tut, was es soll. Und wenn du das nicht weißt, dann weißt du auch nicht, wo ein Fehler oder Bottleneck ist und kannst auch keine gerechtfertigte Vermutung darüber anstellen. Schönheit eines Codes ist also kein Luxus, sondern der Kern vesteh-, wart- und debugbarer Software. Und natürlich Tests.

Serpens66 hat geschrieben: ist dieser natürlich "grottenschlecht" programmiert, sodass wir noch jahrhunderte damit beschäftigt wären, jede kleine Stelle, die unschön programmiert ist zu verbessern... anstatt dem eigentlichem Problem auf die Schliche zu kommen.

Was die Erkenntnis reifen lassen sollte, dass stets danach streben sollte, seinen Code zu sauber wie möglich zu gestalten. Denn damit wäre es vermutlich einfacher, den Fehler einzugrenzen und zu lokalisieren

@BlackJack:
Vielen vielen Dank, genau so eine Antwort wollte ich haben

BlackJack hat geschrieben:@Serpens66: Was das Einfrieren angeht müsstest Du halt möglichst genau eingrenzen wo das hängt. Wenn API-Calls hier Anfragen über das Netzwerk meinen, dann kann das zum Beispiel in der Tat auf eine Antwort warten. Nur davon auszugehen das da eine Zeitüberschreitung ausgelöst wird, reicht vielleicht nicht, das sollte ja dokumentiert sein, oder notfalls muss man den Bibliothekscode halt mit in die Fehlersuche einbeziehen.

Genau mit API calls meine ich Anfragen, die mittels des request moduls an eine API von einer Website geschickt werden und die antworten empfangen werden.
Ich habe mein Skript jetzt nicht auseinandergenommen, aber lasse nun hinter und nach jedem API Call einen Eintrag in meiner Textdatei machen.
Auf diese Weise sollte ich dann beim nächsten Mal erkennen können, welche der 5 APICalls zum Stillstand geführt hat. Sobald ich das weiß, kann ich denke ich genauer Nachforschen, ob es am "Warten auf Antwort" liegt.
Man könnte auch schon jetzt alle 5 Calls untersuchen, aber ich denke es ist sinnvoller abzuwarten, an welchem Call es genau liegt.

BlackJack hat geschrieben: Eventuell ist es auch ein Hardwareproblem? Ich habe einen Wifi-USB-Stick der am Raspi zum Beispiel nach ca. einem Tag Betrieb einfach nicht mehr existiert. Abziehen und wieder Anstecken ist das einzige was hilft bei dem Modell.

Ein Hardware Problem ist sicher nicht auszuschließen. Allerdings wird eine Fehlermeldung generiert (also es wird ein fehler "geraiset") , wenn ich das Internet hier abschalte. Also sollte es ja auch so eine Fehlermeldung geben, wenn der Wifi-USB-Stick (ist dasselbe wie "WLAN-USB-Stick" bzw. der korrekte begriff dafür?) den geist aufgibt.

BlackJack hat geschrieben: Wenn der Pi selber einfriert ist das bei mir immer ein Wärmeproblem gewesen. Da half kein Gehäuse zu verwenden und den so aufstellen das die Wärme sich nicht gestaut hat und nicht zu Übertakten.
Ein anderer Grund der den Raspi total in die Knie zwingt ist wenn der Speicher knapp wird und man eine Auslagerungsdatei auf SD-Karte hat.

Der Pi läuft mit Gehäuse, aber schon so, dass die luftlöcher oben sind und er bei zimmertemepratur lagert. Wenn ich das Gehäuse anfasse, ist es zwar warm, aber defintiv nicht heiß, ich glaube also, dass das kein Problem ist. Falls es ein Problem wäre, würde immer der komplette Pi abstürzen, oder? Also es wäre auch nichts mehr bedienbar, man könnte das terminla nicht mehr schließen usw., oder? Das ist mir bisher noch nicht passiert.

BlackJack hat geschrieben: So grundsätzlich passiert mir das Einfrieren beim Pi nicht. Ich habe einen mit RasBMC als Fernseherersatz 27/7 zu laufen. Da sind auch ein paar Skripte drauf die regelmässig Infos aus dem Netz holen und verarbeiten, OwnCloud, und ein paar private Mercurial-Repositories. Einen zweiten habe ich als „Internetradiowecker” im Betrieb. Und in der Firma haben wir etliche zu Monitoringzwecken und ein paar auch als VPN-Endpoints bei Kunden im Dauereinsatz. Da gab es bisher wenig Probleme und die waren eigentlich immer wegen Wärme. Also an eine Stelle in einem Serverrack die von sich aus schon so um die 35-40° Warm ist, sollte man das Gerät nicht aufstellen.

okay...danke für den erfahrungsbericht

BlackJack hat geschrieben: Der Pi 2 ist zwar schneller, aber natürlich immer noch langsamer als ein ausgewachsener Laptop. Beim 2er hätte man einen Vorteil gegenüber dem 1er wenn sich das Problem ausreichend paralellisieren lässt. Der hat ja vier Prozessorkerne. Ansonsten schafft man sich Raspis ja auch eher an weil sie wenig kosten, wenig Strom verbrauchen, und leise sind, und nicht weil man damit schnell grosse Datenmengen verarbeiten kann.

Es sind definitv keine großen Datenmengen die verarbeitet werden müssen...Das einzige, was ich als "große" Datenmenge bezeichnen würde, ist meine textdatei, die nach 40minuten schon 1MB groß ist... Allerdings sehe ich da keinen Zusammenhang zum "einfrieren", da heute nacht die txt datei noch frisch ausgeleert (also auf den laptop verlagert) wurde und das Skript gerade mal 2 stunden lief, bevor es einfror.

BlackJack hat geschrieben: Was Geschwindigkeit und Speicherverbrauch angeht hilft es vielleicht keine grafische Oberfläche auf dem Raspi laufen zu lassen. Dann kann man vielleicht auch mehr RAM dem Betriebssystem zuweisen statt der ”Grafikkarte”. Wunder darf man da allerdings nicht erwarten.

Das ist eine gute Idee! Die Dateien berabeiten und auswerten tu ich ja eh auf dem Laptop, da brauche ich mittlerweile also keine graphische Oberfläche mehr.
Habe Raspbian installiert. Ich muss das nicht deinstallieren, um auf die ...ähm wie nennt man das... terminaloberfläche(?) zu wechseln, oder?


@pillmuncher und Hyperion:
Natürlich ist es das Ziel sauberen Code zu haben, bzw. schreiben zu können. Und im Vergleich zu vor ein paar Monaten ist mein Code auch schon viel viel übersichtlicher
Das Ganze ist mein allererstes Projekt, welches ich "einfach mal drauflos" geschrieben habe. Ich finde beim Lernen vom Programmieren sollte man wie in der Schule erstmal alles vereinfacht machen, bis man es verstanden hat. Und dann sieht man schon ganz von alleine, dass es einfach so unübersichtlich ist, dass man sich selbst nicht mehr zurechtfindet und dann verbessert man das nach und nach. Sobald man dies ein paar mal gemacht hat, weiß man wie man etwas von vorneherin übersichtlich aufbauen kann und vermeidet unübersichtlichkeit direkt zu Beginn.
So weit bin ich aber noch nicht, dass ich es zu beginn schon so halten kann, ich bin noch in der Phase, wo ich es nach und nach immer ein stück besser mache und damit lerne, wie es man es übersichtlich hält

@Serpens66: Beim Schreiben der Logdatei bedenken das Ausgaben in Dateien üblicherweise gepuffert werden. Wenn Dein Programm hängenbleibt, muss also nicht zwangsläufig schon alles in der Datei stehen was da reingeschrieben wurde wenn man nicht dafür sorgt das der Puffer immer schön rausgeschrieben wird. Was allerdings bei SD-Karte als Massenspeicher dann auf Dauer auch wieder nicht so schön ist. Falls die Logdatei nicht zu gross wird würde ich die wahrscheinlich eher auf eine RAM-Disk schreiben und ggf. rotieren. Dann sind die Daten zwar weg wenn man den Raspi neustartet, was blöd ist wenn er tatsächlich komplett hängt, aber das scheint bei Dir ja nicht der Fall zu sein.

Das Internet abschalten kann aus Sicht des Treibers für so einen WLAN-Chipsatz etwas anderes sein als wenn der Chipsatz aus irgendwelchen Gründen etwas macht was er nicht soll. Denn auf das wegbrechen der Verbindung muss so ein Treiber ja auf jeden Fall sinnvoll reagieren, das passiert in der Praxis ja öfter mal. Aber wenn die Hardware spinnt, kann auch ein Treiber bei für ihn unerwarteten Situationen hängenbleiben.

Wenn der Raspi überhitzt dann hängt in der Regel der komplette Rechner. Das passt nicht zu Deinem Fehlerbild, aber Du hattest ja auch nach Hängern/Problemen allgemein gefragt.

Deinstallieren muss man nichts wenn man bei Rasbian keine grafische Oberfläche haben möchte. Nur in ``raspiconfig`` ausschalten das die automatisch gestartet wird. Dann macht es Sinn sich ``screen`` oder ``tmux`` und vielleicht auch noch ``byobu`` zu installieren (hübscheres ”front end” für die beiden anderen Programme). Damit kann man dann Programme per SSH starten und die Verbindung trennen ohne das die Programme sich beenden und man kann sich später wieder mit den Programmen verbinden.

BlackJack hat geschrieben:So grundsätzlich passiert mir das Einfrieren beim Pi nicht. Ich habe einen mit RasBMC als Fernseherersatz 27/7 zu laufen.

Und ich hatte mich schon immer gewundert wie BlackJack so viel an einem Tag schafft, dabei cheatet er einfach weil sein Tag 3 Stunden mehr hat als unserer

Serpens66 hat geschrieben:Genau mit API calls meine ich Anfragen, die mittels des request moduls an eine API von einer Website geschickt werden und die antworten empfangen werden.
Ich habe mein Skript jetzt nicht auseinandergenommen, aber lasse nun hinter und nach jedem API Call einen Eintrag in meiner Textdatei machen.

Das ist zum Beispiel etwas was du parallelisieren könntest, wenn die Abfragen unabhängig voneinander sind.

Serpens66 hat geschrieben:Habe Raspbian installiert. Ich muss das nicht deinstallieren, um auf die ...ähm wie nennt man das... terminaloberfläche(?) zu wechseln, oder?

Nee, wenn ich mich richtig erinnere statet Rasbian standardmäßig in das Terminal und man muss die grafische Oberfläche manuell starten, aber kann sein dass sich das inzwischen geändert hat. Du kannst aber auch in diesem Raspi-Config-Tool was beiliegt das einstellen ob die GUI gestartet wird.

@Leonidas:
danke für deine Antwort

Nee, wenn ich mich richtig erinnere statet Rasbian standardmäßig in das Terminal und man muss die grafische Oberfläche manuell starten, aber kann sein dass sich das inzwischen geändert hat. Du kannst aber auch in diesem Raspi-Config-Tool was beiliegt das einstellen ob die GUI gestartet wird.

ich weiß es ehrlich gesagt auch nicht ist schon sehr lange her, dass ich den PI neu gestartet habe... und das war nur bei der einrichtung, also vllt 5 mal oderso dass ich überhaupt gesehen habe, wie sowas aussieht, deswegen erinnere ich mich nicht mehr dran ^^
Aber darum kümmere ich mich dann, wenn alles andere soweit optimiert ist

Das ist zum Beispiel etwas was du parallelisieren könntest, wenn die Abfragen unabhängig voneinander sind.

Du meinst die API Calls parallelisieren? Oder den Eintrag in die txt datei? Oder beides ? Ich hab scho beides umgesetzt. Die API Calls stehen in extra funktionen und darin steht dann auch der eintrag in die txt datei. Diese funktionen werden dann parallel aufgerufen.
Wobei ich noch nicht dazu gekommen bin, mein Parallelisierungsprozess zu verbessern, ich nutze immer noch das zusammengebastelte aus diesem Thread:
http://www.python-forum.de/viewtopic.ph ... 79#p269979
(das einfrieren passiert aber auch an dieser stelle, wenn nichts parallelisiert ist, also ist das vermutlich nicht die ursache )

Bisher hält sich der Pi "leider" ganz gut, ist also noch nicht wieder eingefroren... mal schauen, wann es so weit ist..

sooo..

Es ist nun wieder passiert, während ich live dabei war

Und zwar gab es zumselben Zeitpunkt, als mein Bot "einfror" sogar eine Fehlermeldung in meinem Browser auf meinem Laptop, beim Zugriff auf die Seite, von welcher ich per API Infos anfordere.
Mein Browser verwehrte mir den Zugriff auf die Seite mit der Meldung:

Fehler: Beschädigte Inhalte

Die Seite, die Sie anzusehen versuchen, kann nicht angezeigt werden, da ein Fehler in der Datenübertragung festgestellt wurde.

Die Seite, die Sie anzusehen versuchen, kann nicht angezeigt werden, da ein Fehler in der Datenübertragung festgestellt wurde.

Bitte kontaktieren Sie die Website-Betreiber, um sie über dieses Problem zu verständigen.

Habe es schon an den Seitenbetreiber weitergeleitet und der macht hoffentlich was dagegen. Nach ein paar Minuten und einem Browser Neustart, konnte ich wieder auf die Website zugreifen, aber mein Bot blieb eingefroren und lief erst nach einem Neustart weiter.

Also wird es vermutlich tatsächlich daran liegen, dass mein Bot auf Antwort wartet, welche er nie bekommt.

Die Lösung wäre dann vermutlich eine Zeitbegrenzung einzubauen, wie lange er auf Antwort warten soll?

Nutzen tue ich dieses fertige Paket "krakenex"
https://github.com/veox/python3-krakene ... nex/api.py
die definition "def query_public" bzw "def query_private"
Wo müsste ich dort etwas zwischenbauen?

@Serpens66: Wenn man dem Programmfluss der beiden Methoden folgt landet man bei der `Connection`-Klasse und die Methode benutzt für die HTTP-Verbindung einen Timeout von 30 Sekunden.

Stell Dir mal die Frage was bei dem Code dort passiert wenn die Verbindung mal ”kaputt” geht. Ich sehe da nichts was diesen Fall behandelt. Da müsstest Du Dich also selber drum kümmern.

okay, danke schonmal

ich nehme mal an das schlüssel Modul ist http.client.HTTPSConnection ?

Jetzt ist die frage, wie/wo genau "die verbindung" ist. Es könnte sein, dass schon direkt bei self.conn = http.client.HTTPSConnection(uri, timeout = timeout) die Verbindung aufgebaut wird. Oder aber erst bei der Abfrage selbst self.conn.request("POST", url, data, headers) ...

Hier https://docs.python.org/3/library/http.client.html gibts das .request nur für HTTP, nicht für HTTPS, aber ich vermute mal es funktioniert ähnlich/genauso.
Aber ich werde leider nicht schlau aus den Angaben in der Doku, wie das ganze nun funktioniert, also wie sich ein kaputtgehen der Verbindung äußern würde...
Also ich weiß nicht wonach ich suchen müsste und an welcher stelle =/

Da aber ein Neustart des Bots geholfen hat, könnte ich einen Neustart der Verbindung einbauen?
Nur brauch ich auch dafür die genaue Quelle des Einfrierens.. sonst wird der Neustart ja garnicht ausgeführt bzw. ich weiß nicht an welche Stelle ich diesen schalten muss. =/

Eine interessante Sache, die man in der Doku bei getresponse lesen kann ist:

Note that you must have read the whole response before you can send a new request to the server.

Aber angenommen es hängt, weil aufgrund der kaputten Verbindung das vorherige request nicht ausgelesen wurde, würde aufgrund der kaputten Verbindung ja auch request selbst und alles nicht funktionieren, also ist es sehr unwahrscheinlich, dass das die ursache sein könnte... (ich wollts nur mal erwähnt haben ^^)

Heut Nacht kam es wieder vor. Interessanterweise habe ich heute das erste mal kurz vorm Einfrieren eine Fehlermeldung erhalten:
2 sekunden danach hat er die Anfrage zum Orderbook nochmal gesendet (weil das mein try/except block so vorsieht) und vermutlich wurde die Anfrage auch beendet... Ich habe vor und hinter dem Befehl zur Abfrage einen Log Eintrag machen lassen und beide Einträge wurden gemacht. Dennoch ist er nach diesen zwei Einträgen eingefroren.

@Serpens66: ohne Dein komplettes Programm zu kennen, ist das hier doch nur Herumstochern-im-Nebel.

Wenn ich mir Zeile 3 von dem Traceback anschaue dann möchte ich den Quelltext glaube ich gar nicht wirklich sehen.

BlackJack hat geschrieben:Wenn ich mir Zeile 3 von dem Traceback anschaue dann möchte ich den Quelltext glaube ich gar nicht wirklich sehen.

Auweia.

Hebe dich hinfort, Satan!

Zum Lesen: "Eval really is dangerous"

Eval fetzt. Die ganzen Leute mit den zwingend kompilierenden Sprachen sind ja nur neidisch, dass sie nicht sowas schönes eingebaut haben. Für C gibts immerhin den TCC, der für quick&dirty Laufzeitkompilierung einfach auszuliefern ist.

@Sirius3:
wieso? Ihr habt doch den Code von diesem Krakenex Modul. Und blackJack meinte ja schon, dass wenn ein Fehler bei der Verbindung auftritt, dass dieser dort nicht behandelt werden würde. Also haben wir das vermeintliche PRoblem ja schon gefunden. Und ich hab schon gepostet, was ich mir für Gedanken dazu gemacht habe, aber nicht weiß, ob ich nun bei http.client.HTTPSConnection(uri, timeout = timeout) oder erst beim request ansetzen muss. Und ich weiß nicht, wie sich ein Verbindungsfehler äußert (also ein Fehler, der bisher noch nicht erfasst ist... kein Internet und normaler Timeout wird ja erfasst, so wie auch alle anderen Fehler die ein Script zum Abbruch führen würden, da ich dieses private_query Methode in einem try/except block aufrufe und die fehler samt traceback ausgeben lasse), also wie ich einbauen könnte, dass mein Bot diesen erkennt.

zu "eval":
hab den Artikel mal zur hälfte gelesen (die zweite hälfte geht zu tief ins detail und was gezeigt werden soll , wird ja schon am anfang geschrieben).
So lange man aber selbst bestimmt, was in den Klammern von eval steht, besteht da doch überhaupt keine Gefahr?
Was sollte ich denn Alternativ zu eval() nehmen, wenn man eben wie in Zeile drei eine Methode basierend auf einen wählbaren importiertem Modul aufrufen will?

@Serpens66: Wenn man in der Doku zur Standardbibliothek auf den Punkt 2 (von 37) klickt, dann sieht man die Built-in Functions. Diese sollte man alle mal gesehen haben und ungefähr wissen, wofür sie gut sind. Insbesondere möchtest du dich dort über getattr() informieren.