ich bin immer noch damit beschäftigt, die Abstürze des MQTT-Moduls nachzuvollziehen. Dazu suche ich die Bedeutung von Warn- und Fehlermeldungen im Log:
WARNING | Client Socket | Fehler beim Lesen: End of file
WARNING | Client Socket | Fehler beim Schreiben: Ungültiger Dateideskriptor
WARNING | Client Socket | Fehler beim Lesen: Ungültiger Dateideskriptor
Bitte um Hinweis auf die Docu oder Erklärung der Ursachen.
Bei dem Client Socket handelt es sich um den MQTT-Socket zu Mosquitto auf dem raspi. Dessen log-Datei gibt zu diesem Zeitpunkt nur einen Socket Error aus (nach Sending SUBACK )
Ich hänge mich hier mal dran.
Diese Fehlermeldung bekomme ich auch dann und wann. Passiert in Zusammenhang mit einer relativ simpel gestrickten Datenverbindung zu Arduinos. Hab zwar kein direktes Problem, es wäre aber interessant zu wissen was da schiefläuft.
WARNING | Client Socket | Fehler beim Lesen: End of file
den eigentlichen Vorgang hatte ich bereits am 19.8.17 ([Modul] IPS_MQTT) beschrieben. Meine beiden MQTT-Module haben sich irgendwann gegenseitig behindert und dabei mit ständigem Öffnen und Schließen des Sockets aufgeschaukelt, was dann zum Beenden von IPS führte. Leider habe ich das Log nicht mehr und kann deshalb die letzten Zeilen nicht mehr zitieren.
Mein Fehler bei der Installation der Module war wohl, beiden die gleiche ModulID zu geben (habe die Vorgabe übernommen). Dies sollte also in der Zukunft nicht mehr möglich sein. Thomas hat inzwischen sein Modul geändert - ob an dieser Stelle auch, weiß ich nicht.
Seit dem Anlegen der Module mit geänderter ID ist der Fehler nicht mehr aufgetreten.
Vom Log her und einem ähnlichen Fall mit einem anderen Modul weiß ich, dass sich die Sockets im Sekundentakt (oder noch schneller) öffnen und schließen und es dann NICHT mehr möglich ist, den Socket zu deaktivieren. Es bleibt nur noch Löschen und Neustart von IPS. Dies halte ich aber nicht für eine gute Lösung.
Auch wenn die Warn- und Fehlermeldungen direkt vom Socket kommen sollten und nur weitergereicht werden, sagen sie einem unbedarften Anwender doch garnichts - der Mosquitto auf der anderen Seite war da etwas auskunftsfreudiger.
Vom Log her und einem ähnlichen Fall mit einem anderen Modul weiß ich, dass sich die Sockets im Sekundentakt (oder noch schneller) öffnen und schließen und es dann NICHT mehr möglich ist, den Socket zu deaktivieren. Es bleibt nur noch Löschen und Neustart von IPS. Dies halte ich aber nicht für eine gute Lösung.
Das Öffnen und Schließen im Sekundentakt klingt aber eher so, als wenn dein MQTT Modul diesen Vorgang auslösen würde? An der Stelle können wir leider nicht verhindern, dass ein Splitter Modul genau dieses Verhalten hat. Dort müsste der Modulentwickler entsprechend gegenwirken, oder eine Option anbieten, dass man das MQTT Modul deaktivieren kann.
das Modul fragt den Socket normalerweise alle 60 Sekunden ab. In dem geschilderten Fall hat sich der Socket versucht zu verbinden, konnte das wohl nicht, hat es abgebrochen und SOFORT wieder neu versucht. Darauf bezog sich meine Aussage mit den (gefühlten) Sekundentakt.
Was tut nun der Modul-ANWENDER?
er versucht den Socket zu deaktivieren. Dies war auf Grund der Schnelligkeit der Abläufe nicht möglich. Hier ist dann vielleicht nicht nur der Modulentwickler gefragt, denn der greift ja wohl nur auf die Socketkomponente zu. Ein kurzer Timeout vor einem sofortigen retry hätte in dem Fall vielleicht geholfen.
er versucht die Modulinstanz zu löschen. Die war dann nur in Verbindung mit einem Neustart erfolgreich.
er sieht im Logfile nach und erwartet von dort eine Erklärung für die Socketprobleme. Aber dort erfährt er nichts, was ihm weiterhilft.
er bemüht die Suche nach Dokumentation zu Einträgen im Log. Kann er da fündig werden?
Also noch mal meine Frage (vom19.8.), kann/will man die Warn-/Fehlermeldungen zum Client Socket besser verständlich machen als:
Client Socket: Fehler beim Lesen: End of File
Client Socket: Fehler beim Schreiben: ungültiger Dateideskriptor
Client Socket: Fehler beim Lesen: ungültiger Dateideskriptor
und was sagt mir:
KernelMT: Nachricht IM_CHANGESTATUS für ID xx dauerte 179ms
KernelMT: Nachricht IM_CHANGESTATUS für ID xx dauerte 179ms
Dies ist nur eine Hinweismeldung, weil du in den Spezialschaltern die Option „Verarbeitungswarteschlange protokollieren“ aktiviert hast. Das sagt, dass bei einer Verarbeitung eine leichte Verzögerung von 179ms aufgereten ist - was OK ist. Ich würde dir empfehlen diese Option zu deaktivieren, da die Meldung eher für uns zum Debuggen sind. Wir würden dir Bescheid geben, wenn du diese aktivieren sollst.
Bei den anderen Fehlermeldungen kann ich eigentlich nicht „mehr“ sinnvolle Informationen geben. Ich könnte weniger geben und einfach sagen, dass es einen Verbindungsabbruch gab. Warum dies so ist, kann ich dir leider anhand der Meldungen auch nicht genau sagen.
danke für die Informationen. Den MessageQueueWatch habe ich jetzt ausgestellt. Schade, dass die internen Fehlermeldungen beim Socket nicht mehr hergeben.