Beta Test js-controller 3.0.x auf GitHub
-
@ilovegym Aah dann bist Du das
bisher ist da immer der controller gecrasht. ENOMEM heisst das der Prozess nicht gestartet werden konnte weil kein RAM mehr frei ist ...Schau Dir mal dein system genau an bzw reboote mal.
-
@e-i-k-e sagte in Beta Test js-controller 3.0.x auf GitHub:
Also bei mir sieht es so aus als ob die Instanz hier ein Problem beim stoppen hat. Hängt vllt irgendeins der Skripte oder so? In jedem Fall verhält sich das System laut Log korrekt.
Beim Slave sehe ich in dem Log Auszug:- 11:26:19.440 controller sagt prozess 27154 er solle sich beenden
- 11:26:19.440 adapter hat nicht reagiert, controller sendet dem prozess ein kill signal 27154
- 11:26:21.611 controller startet neuen prozess (7635)
- 11:27:02.372 prozess 27154 meldet das er das erste Skript gestoppt hat
- 11:27:03.439 prozess 7635 beendet sich weil noch ein anderer läuft
- 11:27:34.735 controller startet neuen prozess (7769) ... der startet weil der andere Prozess ewig sein alive nicht mehr aktualisiert hat
*11:28:01.522 prozess 27154 läuft immer noch und bekommt JETZT erst die Info über state changes vom 7635 start (1:40 Minuten später!!) und dnan alle - 11:29:05.153 ENDLICH beendet sich 27154 (2:46 Minuten nachdem er den Kill befehl erhalten hat)
Alles in Allem schau ich mal was ich optimieren kann, aber fakt ist das irgendein Skript deine Instanz mega blockiert und damit alles durcheinander bringt ... Finde das Skript und fixe es
Um das Thema zu ohne Skript Fix zu beheben musst Du schauen das du stop drückst, wartest bis der alte prozess wirklich weg ist und dann neu startest.
-
@ilovegym Versuch mal rauszufinden wann genau das kommt. Also welchen Visu adapter du aufrufen musst damit das im Log kommt. und dann bei dem ein "iobroker upload NAME" ausführen .
-
@Homer-J sagte in Beta Test js-controller 3.0.x auf GitHub:
läuft zwar ich kann a
Bitte Issue beim Adapter öffnen
-
@Homer-J sagte in Beta Test js-controller 3.0.x auf GitHub:
läuft zwar ich kann aber nichts schalten es reagiert nichts.
Log?
-
Hi @apollon77 Hab heut morgen die 3.0.9 Version installiert im Anschluss die Node.js auf die 12.. Version angehoben nochmal zur Sicherheit den Fixer drüber laufen lassen und seitdem läuft er.
-
Bei mir gibts zwar keine Fehler im Log und alle Adapter sind grün, aber einige Scripte haben gesponnen und der TR-064 findet keine Geräte mehr.
Bin gerade dabei ein Backup zurück zuspielen um zu testen, ob es tatsächlich am JS liegt, oder sich einfach das System was eingefangen hat. -
@Homer-J Und Yahka tut?
-
@Jan1 Hm ... ohne Details schwierig
-
@apollon77
läuft -
@apollon77
Wenn keine Fehler im Log stehen ist es eben etwas blöd mehr zu sagen. Augenscheinlich lief ja alles, mich hatte heute gewundert, warum der Saugroboter nicht lief. Der fährt nur bei Abwesenheit und der DP wurde das letzte mal am WE geändert. Dann geschaut ob der TR-064 mein Handy im WLAN erkennt und das bliebt auf true, ebenfalls das Handy meiner Holden, die immer noch samt Handy auf Arbeit ist.
Das Backup ist drauf und der TR-064 läuft wieder. Nun kommt der JS 3.0.9 dazu, mal sehen ob s dann immer noch läuft -
@Jan1 tr-064 gabs aber ne gefixte version für den neuen controller ...
-
@apollon77
Ich geh mal davon aus, dass es genau an der lag, da ich die über Github geladen hatte. Ich nutze zwar keine Anrufliste, hatte den aber trotzdem drauf. Der kommt auch gleich wieder drauf
-
@e-i-k-e Achja um hier zusehen ob du ein problem mit den Skripten hast gibts noch einen Weg. Bei den Objekten gibt es system.adapter.javascript.2.eventLoopLag ... schau die den mal an. Der sollte im Idealfall nur seeeehr klein sein (sind Milisekunden). Normal ist alles ich sag mal kleiner 30, was ist der Wert denn bei Dir so? Gff logge den mal per history oder so und dann schau.
Wenn der Wert große Werte hat dann blockiert irgendetwas die Abarbeitung und dann muss Du schauen
-
Hi,
ich habe mit die Probleme von e-i-k-e nochmal genauer angesehen. Aus dem bereits analysierten gibt es einerseits die 3.0.10 auf GitHub, die noch etwas verbessert generell
3.0.10 (2020-04-15) Release Elena
- (Apollon77) consider the Adapter Stop Timeout also for adapter restarts to give adapters enough time to stop before restarting
In dem obigen Fall wo der Adapter über 2 Minuten blockiert bevor er sich mal neu startet bringt der Fix nichts, dafür hab ich ein Issue angelegt. Das zu optimieren ist etwas aufwändiger und für den Fortschritt den wir mit der 3.0 schon haben "zu gross". Sehe ich aber für die 3.1 vor.
-
Ich habe gerade den js-controller 3.0.9 bei mir getestet. Alle Adapter starten problemlos bis auf den Robonect-Adapter. Dieser verweigert den Start mit folgender Fehlermeldung:
robonect.0 2020-04-15 15:48:22.309 error at processTicksAndRejections (internal/process/task_queues.js:97:5) robonect.0 2020-04-15 15:48:22.309 error at /opt/iobroker/node_modules/iobroker.robonect/lib/library.js:112:32 robonect.0 2020-04-15 15:48:22.309 error (31968) TypeError: self.pollGPs is not a function robonect.0 2020-04-15 15:48:22.308 error (31968) uncaught exception: self.pollGPs is not a function robonect.0 2020-04-15 15:47:49.046 error at processTicksAndRejections (internal/process/task_queues.js:97:5) robonect.0 2020-04-15 15:47:49.046 error at /opt/iobroker/node_modules/iobroker.robonect/lib/library.js:112:32 robonect.0 2020-04-15 15:47:49.046 error (31220) TypeError: self.pollGPs is not a function robonect.0 2020-04-15 15:47:49.045 error (31220) uncaught exception: self.pollGPs is not a functionGruß Marco
-
@lonsimbt Der Fehler kommt irgendwo "aus dem Adapter". Wüsste nicht wie der controller da was mit zu tun haben könnte
-
@lonsimbt PS: EInzige as sein kann ist das der Fehler schon immer da war aber bisher "nur" eine unhandled Promise rejection war die nicht zum adapter-crash geführt hat ... mit 3.0er controller ist es das aber. Da muss der Entwickler ran
-
@apollon77 gerade installiert vom git, ist aber noch der 3.0.9
-
@deta Mach nochmal, da fehlten noch 2 Files
