NEWS
UNSOLVED Absturz-Loop von "host.IO-Broker" - nichts geht mehr.
-
Hallo zusammen
seit kurzem habe ich das Problem, dass sich IO-Broker im ~10 Sekunden-Takt neu startet.
Laut LOG auf Grund eines Syntax Errors (sieh Bild) der mir aber nichts sagt bzw. ich mir auch nicht 100% erklären kann woher dieser kommt.Ich gehe an Hand der Meldung von einem Problem mit VIS aus. Ich hatte u.a versucht eine Webcam einzubinden.
Das würde auch die Meldung ein Stück weit erklären. Jedoch habe ich in dem entsprechend View alle Widgets gelöscht.
Mittlerweile habe ich auch die komplette VIS-Instanz deaktiviert usw.
Dennoch startet IO unentwegt neu und ich bin momentan ziemlich ratlos.Ich habe auch begonnen auf File-Ebene nach der Passage "{camera_1.showJpegFrame(jpeg, serverUrl, token, id)/" zu suchen,
um diese ggf. zu entfernen oder wenigstens die Datei zu identifizieren welche das Ganze auslöst, jedoch bis dato ohne Erfolg.Ich in für jeden Tipp dankbar. Grüße John
-
UPDATE:
Ich konnte es nun nach etwas Recherche soweit eingrenzen, dass der Loop gestoppt wird wenn ich die Instanz "web.0" temp. deaktiviere.
Genauer kann ich Web.0 nutzen solange ich in den Einstellungen "socketio" nutze anstelle von "integriert".
Damit funktionieren allerdings einige andere Instanzen, bspw. cloud.0 oder alexa2.0 nicht ordentlich.
VIS lässt sich so aber wieder verwenden.
Wenigstens für mein debugging ein ganz guter AusgangspunktDa VIS auf dieser Instanz direkt aufsetzt (für das Socket-Handling sofern ich das soweit richtig verstanden habe) gehe
ich jedoch immer noch davon aus, dass der Auslöser ein defektes Widget in VIS ist.
Genauer sieht es wohl so aus, dass dieses Widget noch auf einem meiner Clients (VIS-App) aktiv ist, da ich dort die letzten Änderungen noch nicht neu geladen habe und jedes mal wenn eben dieser Client versucht durch VIS über web.0 eine Verbindung aufzubauen es letztlich zu dem Syntax-Fehler kommt.
Deswegen nützt es mir auch nichts das ich das defekte Widget in meiner VIS-Config auf dem Server längst entfernt habe.Das kann ich leider erst testen wenn ich den Client greifbar habe.
Interessant wäre aber um so mehr zu klären wieso ein basic HTML widget bei Einbindung einer Webcam per jpeg zu einem solchen Phänomen führt. Geaue Settings des besagten Widgets müsste ich nochmal suchen...
-
Also der Fehler ist doch eindeutig ... irgendwo ist scheinbar ein Skript falsch bzw irgendwas setzt ein Falsche regex oder Parameter sind durcheinander.
Das was in der Fehlermeldung steht mit dem setTimeout ... such mal danach wo das herkommt
-
Hi danke für die Rückmeldung.
Also was jetzt "eindeutig" ist darüber können wir sicher lange streiten
Das WOHER war genau das Problem, denn das war eben leider so gar nicht so eindeutig.Wie ich aber bereits vermutet hatte, war es am Ende ein HTML Widget in VIS über das ich ein Webcam-Bild eingebunden hatte.
Das Widget war zum Zeitpunkt der Abstürze aber bereits in VIS gelöscht, VIS wie erwähnt komplett deaktiviert.
Dennoch kam es zu weiteren Abstürzen. Und das macht einen dann doch erst mal ratlos
Das LOG ist für mich als Leihe da einfach zu unklar als das ich da direkt Rückschlüsse auf VIS gezogen hätte.
Der Loop kam erst Stunden nach meinen Tests mit dem Widget in VIS, wie gesagt zu einem Zeitpunkt als ich die Widgets längst wieder gelöscht hatte deswegen sah ich da auch erst mal keinen Zusammenhang.Meine ursprüngliche Vermutung war aber korrekt, dass ein Tablet auf dem die VIS-App läuft noch einen alten Stand meiner VIS-Oberfläche geladen hatte - den mit dem defekten Widget. Es kam somit jedes Mal zum Absturz sobald dieser Client versucht hat sich mit IO zu verbinden. Und das obwohl die VIS Instanz längst deaktiviert wurde.
Somit konnte ich die Passage im Log auch auf dem gesamten Server in keine Datei mehr finden da der auslösende Skript /Kommando was auch immer auf einem externen Gerät lief.Die Lösung war am Ende VIS auf dem Server wieder zu aktivieren, den Webserver auf "integriert" umzustellen sodass VIS auch wieder per Socketverbindung erreichbar ist, um die letzte Version meiner Oberfläche OHNE defektes Widget auf das Tablet zu laden (re-sync). Dabei musste ich mich sehr beeilen da nach ca. 15 Sekunden der Neustart kam.
Ich bin gerade dabei den Fehler mit besagtem HTML Widget nachzustellen - lässt sich sicher reproduzieren.
Wäre ja vll. schön zu wissen wieso es da zu solchen Abstürzen kommt...EDIT:
dieses Skript innerhalb eines HTML Widgets löste den Absturz wohl aus.<img id="jpeg_1" width="1920" height="1080"> <script type="text/javascript"> var camera_1 = { addEvent: function(elem, event, func ){ if (typeof (window.event) != 'undefined') {elem.attachEvent('on' + event, func);} else {elem.addEventListener(event, func, false);} }, initCamera: function(jpeg, serverUrl, token, id, interval){ this.addEvent(jpeg, 'load', function(){setTimeout(function() {camera_1.showJpegFrame(jpeg, serverUrl, token, id);}, interval);}); this.showJpegFrame(jpeg, serverUrl, token, id); }, showJpegFrame: function(jpeg, serverUrl, token, id){ jpeg.src = serverUrl+"/Jpeg/"+id+"?authToken="+token+"&"+new Date().getTime(); } } camera_1.initCamera(jpeg_1, "http://xxx:yyy", "1234-123-123-123", 1, 40); </script>
alternativ verwende ich nun eine Abfrage per MJPEG:
<img id="mjpeg_1" src="http://x.x.x.x.:yyyy/Mjpeg/1?authToken=123-123-123-123-123" width="1920" height="1080"/>