Adapter starten automatisch ständig neu
-
Da nur ein Post mit einem Link drin ist, kann das doch nicht so schwer sein, den zu finden. `
Stimmt
Hättest aber auch schreiben können in seinem Post verlinkt - oben ist für mich oben Und da stand nunmal Dokumentation Dankechön für den Hinweis vg
Marc
-
Das ist das was Rainer wohl gemeint hat
Man kann schreiben wo und was man will, ein User versteht das immer anders als man es meint
Aber schön, dass ich Dich jetzt doch noch auf den richtigen Pfad führen konnte.
-
-
Ich habe einen ähnlichen Effekt, nämlich dass sporadisch alle Adapter automatisch neu gestartet wird, obwohl die Adapter noch laufen.
Log Files sehen ähnlich aus. Dies führt zu mehrfachen Subscriptions. Ein Unsubscribe zu Beginn eines Scripts genügt nicht, um die alrten Subscriptions los zu werden.
Letzte Woche hatte ich den Fall, dass alle Scripts 6-mal parallel gelaufen sind, was an den Folgeaktionen und Log-Files bestätigt werden konnte.
Ein manueller Neustart des JS-Script Adapters löst das Problem, ein Reboot natürlich erst recht, aber ich häte natürlich gerne, dass das Ganze stabil läuft.
Ich habe keinen Anhaltspunkt, wodurch der Neustart einens Scripts ausgelöst wird. Es läuft über Wochen stabil und dann plötzlich nachts kommt es zu Fehlern.
! 2018-09-05 01:10:48.747 - error: discovery.0 already running
! 2018-09-05 01:10:48.776 - info: hm-rpc.1 starting. Version 1.7.4 in /opt/iobroker/node_modules/iobroker.hm-rpc, node: v8.11.4
! 2018-09-05 01:10:48.793 - info: ping.0 starting. Version 1.3.2 in /opt/iobroker/node_modules/iobroker.ping, node: v8.11.4
! 2018-09-05 01:10:49.081 - error: email.0 already running
! 2018-09-05 01:10:49.105 - warn: javascript.0 Reconnection to DB.
! 2018-09-05 01:10:48.909 - error: host.PI1 instance system.adapter.discovery.0 terminated with code 7 (Adapter already running)
! 2018-09-05 01:10:48.910 - info: host.PI1 Restart adapter system.adapter.discovery.0 because enabled
! 2018-09-05 01:10:48.924 - error: host.PI1 instance system.adapter.web.0 terminated with code 7 (Adapter already running)
! 2018-09-05 01:10:48.924 - info: host.PI1 Restart adapter system.adapter.web.0 because enabled
! 2018-09-05 01:10:49.220 - warn: hm-rpc.2 Reconnection to DB.
! 2018-09-05 01:10:49.228 - warn: hm-rpc.2 Reconnection to DB.
! 2018-09-05 01:10:49.266 - error: hm-rpc.0 already running
! 2018-09-05 01:10:49.287 - error: host.PI1 instance system.adapter.hm-rega.0 terminated with code 7 (Adapter already running)
! 2018-09-05 01:10:49.323 - info: javascript.0 starting. Version 3.6.4 in /opt/iobroker/node_modules/iobroker.javascript, node: v8.11.4
! 2018-09-05 01:10:49.328 - info: admin.0 starting. Version 3.4.7 in /opt/iobroker/node_modules/iobroker.admin, node: v8.11.4
! 2018-09-05 01:10:49.334 - info: ping.0 starting. Version 1.3.2 in /opt/iobroker/node_modules/iobroker.ping, node: v8.11.4
! 2018-09-05 01:10:49.287 - info: host.PI1 Restart adapter system.adapter.hm-rega.0 because enabled
! 2018-09-05 01:10:49.297 - error: host.PI1 instance system.adapter.email.0 terminated with code 7 (Adapter already running)
! 2018-09-05 01:10:49.297 - info: host.PI1 Restart adapter system.adapter.email.0 because enabled
! 2018-09-05 01:10:49.307 - error: host.PI1 instance system.adapter.hm-rpc.0 terminated with code 7 (Adapter already running)
! 2018-09-05 01:10:49.307 - info: host.PI1 Restart adapter system.adapter.hm-rpc.0 because enabled
! 2018-09-05 01:10:49.379 - info: javascript.0 requesting all states
! 2018-09-05 01:10:49.380 - info: javascript.0 requesting all objects
! 2018-09-05 01:10:49.425 - info: javascript.0 starting. Version 3.6.4 in /opt/iobroker/node_modules/iobroker.javascript, node: v8.11.4
! 2018-09-05 01:10:49.433 - info: javascript.0 requesting all states
! 2018-09-05 01:10:49.434 - info: javascript.0 requesting all objects
! 2018-09-05 01:10:50.353 - warn: ping.0 please update js-controller to at least 1.2.0
! 2018-09-05 01:10:51.354 - warn: ping.0 please update js-controller to at least 1.2.0
! 2018-09-05 01:10:51.539 - info: hm-rpc.1 starting. Version 1.7.4 in /opt/iobroker/node_modules/iobroker.hm-rpc, node: v8.11.4
! 2018-09-05 01:10:51.556 - info: admin.0 starting. Version 3.4.7 in /opt/iobroker/node_modules/iobroker.admin, node: v8.11.4
! 2018-09-05 01:10:51.560 - info: admin.0 requesting all states
! 2018-09-05 01:10:51.560 - info: admin.0 requesting all objects
! 2018-09-05 01:10:51.561 - info: admin.0 Request actual repository…
! 2018-09-05 01:10:51.772 - info: hm-rpc.1 xmlrpc server is trying to listen on 192.168.188.40:2011
! 2018-09-05 01:10:51.772 - info: hm-rpc.1 xmlrpc client is trying to connect to 192.168.188.11:2010 with ["http://192.168.188.40:2011","hm-rpc.1"]
! 2018-09-05 01:10:52.183 - info: hm-rpc.1 xmlrpc <- listDevices ["hm-rpc.1"]
! 2018-09-05 01:10:52.723 - warn: ping.0 please update js-controller to at least 1.2.0
! 2018-09-05 01:10:52.831 - info: hm-rpc.2 starting. Version 1.7.4 in /opt/iobroker/node_modules/iobroker.hm-rpc, node: v8.11.4
! 2018-09-05 01:10:53.609 - info: hm-rpc.2 starting. Version 1.7.4 in /opt/iobroker/node_modules/iobroker.hm-rpc, node: v8.11.4
! 2018-09-05 01:10:54.013 - info: hm-rpc.1 xmlrpc -> 0 devices
! 2018-09-05 01:10:54.302 - info: hm-rpc.1 xmlrpc server is trying to listen on 192.168.188.40:2012
! 2018-09-05 01:10:54.303 - info: hm-rpc.1 xmlrpc client is trying to connect to 192.168.188.11:2010 with ["http://192.168.188.40:2012","hm-rpc.1"]
! 2018-09-05 01:10:54.428 - info: javascript.0 received all states
! 2018-09-05 01:10:54.958 - info: admin.0 received all states
! 2018-09-05 01:10:54.984 - info: hm-rpc.2 binrpc server is trying to listen on 192.168.188.40:8702
! 2018-09-05 01:10:54.985 - info: hm-rpc.2 binrpc client is trying to connect to 192.168.188.11:8701 with ["xmlrpc_bin://192.168.188.40:8702","hm-rpc.2"]
! 2018-09-05 01:10:55.388 - info: hm-rpc.1 xmlrpc <- newDevices 111
! 2018-09-05 01:10:55.431 - info: hm-rpc.1 new HmIP devices/channels after filter: 0
! 2018-09-05 01:10:55.665 - info: hm-rpc.1 xmlrpc <- listDevices ["hm-rpc.1"]
! 2018-09-05 01:10:55.695 - info: hm-rpc.1 xmlrpc -> 0 devices
! 2018-09-05 01:10:55.979 - info: hm-rpc.2 binrpc -> listDevices 108
! 2018-09-05 01:10:55.982 - info: hm-rpc.2 binrpc server is trying to listen on 192.168.188.40:8703
! 2018-09-05 01:10:55.983 - info: hm-rpc.2 binrpc client is trying to connect to 192.168.188.11:8701 with ["xmlrpc_bin://192.168.188.40:8703","hm-rpc.2"]
! 2018-09-05 01:10:56.094 - info: hm-rpc.2 new CUxD devices/channels after filter: 0
! 2018-09-05 01:10:56.787 - info: hm-rpc.1 xmlrpc <- newDevices 111
! 2018-09-05 01:10:56.810 - info: hm-rpc.1 new HmIP devices/channels after filter: 0
! 2018-09-05 01:10:56.968 - info: hm-rpc.2 binrpc -> listDevices 108
! 2018-09-05 01:10:56.990 - info: javascript.0 received all objects
! 2018-09-05 01:10:56.994 - info: hm-rpc.2 new CUxD devices/channels after filter: 0
! 2018-09-05 01:10:57.069 - info: admin.0 received all objects
! 2018-09-05 01:10:57.448 - info: admin.0 requesting all states
! 2018-09-05 01:10:57.449 - info: admin.0 requesting all objects
! 2018-09-05 01:10:57.449 - info: admin.0 Request actual repository…
! 2018-09-05 01:10:57.557 - error: admin.0 port 8081 already in use
! 2018-09-05 01:10:58.425 - error: host.PI1 instance system.adapter.admin.0 terminated with code 1 ()
! 2018-09-05 01:10:58.425 - info: host.PI1 Restart adapter system.adapter.admin.0 because enabled
! 2018-09-05 01:10:58.450 - info: host.PI1 Update repository "default" under "http://download.iobroker.net/sources-dist.json"-Jochen
-
"Reconnection to DB" ist hier scheinbar die Ursache.
In js-controller 1.5.0 wird das in der Form nicht mehr passieren das die Adapter Ihre Logik sich neu starten deswegen … den Grund dafür solltest DU aber prüfen und fixen!
"Reconnection to DB" bedeutet das der entsprechende Adapter 20 Sekunden am Stück beschäftigt war ODER 20s lang keinerlei Rechenzeit abbekommen hat (kann beides passieren). Dann reisst die Verbinsung zur States bzw Object-DB ab und wird neu aufgebaut und dann passieren komische Dinge.
Also: Grund-Ursache für die Reconnections finden!
-
Hallo habe das Problem auch, aber eher selten. Habe es aber nur mit der 2. Instanz des JavaScript Adapter auf dem raspi. Habe ein multihost System. Am master /tinker habe ich das Problem nicht.
Auf welche Datenbank greift der Javascript Adapter vom slave zu bzw. Wo liegt die vom slave? Auf dem Master? Könnte es dann ein netzwerkthema sein?
Gesendet von meinem CLT-L09 mit Tapatalk
-
Die DBs liegen immer beim Master Host. Also ja könnte Netzwerk sein. Oder andere Dinge … das müsste man rausfinden
Gesendet vom Handy ...
-
Hab mal den tankerkonig runter geschmissen der shedule von dem Adapter Start stop gefällt mir nicht… Und nutzen tu ich es eh net.. Den history adapter hab ich mal auf den Master umgezogen somit konnte auch die Web Instanz entfallen. Das alles vermindert den traffic im Netz und schont Ressourcen auf dem slave.. Der tinker hat jetzt mehr Arbeit wegen dem history adapter ist auch gleich mal 7 Grad wärmer. Neustart des JavaScript Adapter ist weniger jetzt. Ist heute aber nochmal aufgetreten.. Mal weiter beobachten... Vlt ist ja das alte verlegte Telefonkabel welches ich als netzwerkkabel vergewaltige das Nadelöhr...zwischen meinem raspi und dem tinker... Aber 100mbit schafft das Kabel trotzdem... Der Rest ist 1Gbit LAN.. Vlt Spanne ich mal ne waescheleine um das auszuschließen...
Gesendet von meinem CLT-L09 mit Tapatalk
-
Denke ich hab die Ursache gefunden.. Der raspy Netzwerk chip teilt sich seine Ressourcen mit den USb Anschlüssen. Noch dazu kann der auch nur 100mbit.
An USB habe ich noch den USB Modus Adapter und ein zigbee Stick angeschlossen. Der Modus Adapter hat bei mir mit 1000ms gepollt… Das habe ich jetzt mal auf 5s erhöht... Eigentlich hatte ich fuer die Position ja ein tinker geplant.. Hier gibt es aber keinen gescheiten Adapter der gpio lesen und schreiben kann. Deshalb ist der slave hier immer noch ein raspi.. Weil ich hier diverse Informationen im verteilerschrank einlese und schalte..
Gesendet von meinem CLT-L09 mit Tapatalk
-
War es doch nicht… Bin mit der npm Version wieder auf die 4.1.6..mal sehen ob es daran lag...
Gesendet von meinem CLT-L09 mit Tapatalk
-
npm kann es nicht sein.
Also gleicher Tipp wie beianderen. Adapter ausschalten und langsm einschalten und dann muss Du schauen was genau passiert zu dem Zeitpunkt wo das Spiel mit den neustarts losgeht!!
Was sagt "top" zu dem zeitpunkt zu CPU, RAM und so? Sagt /var/log/syslog irgendwas - vor allem falsl" killer" vorkommt.
Was genau sagt das ioBroker Logfile. Weil: Wenn der js.controller versucht einen Adapter neu zu starten hat er ja einen Grund. Den Muss man rausfinden. Und wenn es "Reconnect to DB" ist dann hat irgendwas den Adapter oder den js.controller für >20 Sekunden blockiert!
Ist History im EInsatz? Passiert da genau was zu dem zeitpunkt? Dann wäre I/O limitierend
-
Danke fuer die Tipps. Werde das alles mal durchgehen.. Aber ja es ist reconnect to DB…meistens der Javascript Adapter 2. Instanz der auf dem slave läuft. Das passiert auch nur am slave. Und history ist auch im Einsatz.. Der loggt meine zaehlerdaten und ein paar Raumklima und wetterdaten..der läuft auf dem tinker Master.. Kann redis fuer Abhilfe schaffen? Hatte das eigentlich aktiviert aber erkenne nirgends ob das läuft..
Auf dem Master läuft noch die pivccu.. Wuerde es was bringen das auszulagern?
Gesendet von meinem CLT-L09 mit Tapatalk
-
Reconnect to DB fehler heisst das die Verbindung zum Master (und/oder redis je nachdem) für mehr als 20 Sekunden "weg" ist ODER der Adapter-prozess über 20 Sekunden etwas anderes tut und daher der regelmäßige "ping pong" nicht ausgeführt werden kann.
Wenn es nur ein Adapter ist der hier auf dem Slave Probleme macht und andere Instanzen laufen (und es noch ein JS-Adapter ist) dann würde ich hier mal alle Skripte prüfen ob da Logik drin ist die dafür sorgen könnte das ne Endlosschleife oder wenigstebs ne lange blockierende Aktion/Schleife passieren kann.Auch schauen - wenn der relevante io.javascript.2 prozess auf dem Slave auf 100% steht dann ist da ein Skript was blockiert.
Wenn es der Master wäre dann wären es mehrere Adapter die das problem haben
Alle Aussagen sind natürlich "Wahrscheinlichkeitsbewertung" unterworfen und können nicht 100% korrekt sein
-
auf dem slave laufen nur ein paar scripte welche wegen exec Funktionen auf den slave wirken sollen. Nur deshalb hab ich überhaupt eine 2. Instanz vom Javascript Adapter. Die selben scripte laufen auch nochmal auf dem Master. Das habe ich schon ausgeschlossen.. Hast du ne
"Idee wie man kontrollieren kann ob redis tut was es soll? "
Hat mir paul53 gerade in einem andere Threat beantwortet…
Redis Scheint bei mir nicht zu laufen...
Kann ein laufendes Redis die Situation verbessern?
Aktuell wird bei mir die Datei States.json beschrieben und nicht die dump.rdb
Gesendet von meinem CLT-L09 mit Tapatalk
-
Naja Redis is optional und macht ab einer gewissen Anzahl an "regelmäßigen Statusaktualisierungen" sinn. Alsoja kann helfen, aber wir kennen ja Dein Problem noch gar nicht
Am besten versuch deinen Slave mal mit "top" oder so zu beobachten und so einen Zeitpunkt zu erwischen wenn er anfängt Probleme zu machen.
-
Danke für den Tipp..
Also schau mir das gerade mit top an .
Am Master / Tinker macht der javascriptAdapter im Vergeleich so zwischen 3 und 10 % CPU Last, geht aber auch schon mal auf 30 hoch. Beim Neustarten des Javascript Adapter macht der schonmal 90% während der startphase…
Am Slave / Raspi 3B macht der Javascript Adapter ähnliche Sprünge ist aber von den Werten her höher da weniger CPU Leistung geht der auch mal bis 10 hoch. Beim Neustart hier uch 90% Auslastung während der startphase..
Kann man das irgendwie mitloggen oder schreibt top das in eine Datei wenn ich das laufen lasse. Dann würde ich mal die Ereignisse anhand der Reconnect und Neustart Zeiten vergleichen...
-
Also ich finde nix auffälliges. Es laufen nur noch 4 Adapter auf dem Raspi. Alles andere habe ich auf den Tinker master geladen…Das Tinker läuft wie ein Uhrwerk..Hatte irgendwann mal swap am raspi deaktiviert. ..Kann das auswirkungen darauf haben?
-
master und host neues image und backup aufgespielt…Jetzt ist ruhe..Danke für die Unterstüzung...
