Beta-Test js-controller 2.2.x GitHub
-
Mir ist noch ein Problem aufgefallen:
Ich habe 2 Systeme im Multihost, master auf 2.1.1 gelassen und slave von 2.1.1 auf 2.2.4 aktualisiert. Nach dem Update hat es mir die https Zertifikate überschrieben. Normalerweise habe ich da ein Pfad zum Dateisystem vom master stehen, aber nach dem Update standen dort generierte Zertifikate vom slave drin. Ist das so gewünscht oder soll ich ein github issue anlegen?
-
@twonky cool. Danke. Ich verstehe immer noch Nicht warum die re-subscribes nicht tun aber naja. Jetzt wird im Zweifel nochmal subscribed. Danke!!
-
@twonky was hast du genau wie angegeben? Der „setup First“ Prozess hat seit der 2.0/1 einen Mechanismus drin das das Zertifikat geprüft wird und wenn es nicht mehr gültig ist oder zu schwach oder zu lang gültig ist dann werden neue Zertifikate erzeugt.
Wie sieht denn dein System.cerrificates Objekt aus? Poste bitte mal.
-
@apollon77 Moin, habe heute morgen ein update vom Bring! Adapter gemacht, und jetzt wollte ich die Instanz und den Adapter löschen, da ich den eigentlich nicht mehr benötige (Alexa2 sei Dank)...
Habe einen ganz komischen Effekt, wenn ich im Admin ( 3.7.5) ( js-controller 2.2.4, Node 10.17.0, NPM 6.13.0) die Instanz löschen lasse, löscht er sie, anschließend öffnet sich aber die Konfig-Seite vom Bring-Adapter und die Instanz ist wieder da.
Im Log steht "packet manager not found" ..Wenn ich die Instanz stoppe, dann läuft auch kein Process mehr, hab auch mal die ganze VM rebootet... mit nem anderem Adapter das gleiche.. hmm hat noch jemand das Problem?
Hier das log ( hab mal dem rtsp-adapter getestet)( 11.41 Uhr nochmal bearbeitet auf debug)
2019-12-31 11:39:35.775 - info: host.iobroker "system.adapter.rtspStream.0" enabled 2019-12-31 11:39:35.798 - info: host.iobroker instance system.adapter.rtspStream.0 started with pid 5753 2019-12-31 11:39:35.890 - info: host.iobroker instance system.adapter.openweathermap.0 terminated with code 0 (NO_ERROR) 2019-12-31 11:39:36.357 - debug: rtspStream.0 (5753) Redis Objects: Use Redis connection: 0.0.0.0:9001 2019-12-31 11:39:36.397 - debug: rtspStream.0 (5753) Objects client ready ... initialize now 2019-12-31 11:39:36.401 - debug: rtspStream.0 (5753) Objects create System PubSub Client 2019-12-31 11:39:36.401 - debug: rtspStream.0 (5753) Objects create User PubSub Client 2019-12-31 11:39:36.402 - debug: rtspStream.0 (5753) Objects client initialize lua scripts 2019-12-31 11:39:36.425 - debug: rtspStream.0 (5753) Objects connected to redis: 0.0.0.0:9001 2019-12-31 11:39:36.428 - debug: rtspStream.0 (5753) objectDB connected 2019-12-31 11:39:36.430 - debug: rtspStream.0 (5753) Redis States: Use Redis connection: 0.0.0.0:9000 2019-12-31 11:39:36.443 - debug: rtspStream.0 (5753) States create User PubSub Client 2019-12-31 11:39:36.461 - debug: rtspStream.0 (5753) States create System PubSub Client 2019-12-31 11:39:36.512 - debug: rtspStream.0 (5753) States connected to redis: 0.0.0.0:9000 2019-12-31 11:39:36.513 - debug: rtspStream.0 (5753) statesDB connected 2019-12-31 11:39:37.252 - info: rtspStream.0 (5753) starting. Version 0.0.1 in /opt/iobroker/node_modules/iobroker.rtspStream, node: v10.17.0 2019-12-31 11:39:37.271 - debug: rtspStream.0 (5753) Starting rtsp Stream 2019-12-31 11:39:37.371 - debug: rtspStream.0 (5753) State Change: rtspStream.0.startStream to true ack false 2019-12-31 11:39:37.372 - debug: rtspStream.0 (5753) Start stream on rtsp://admin:admin@192.168.0.88/12with port 554 2019-12-31 11:39:43.201 - info: host.iobroker iobroker del rtspStream.0 2019-12-31 11:39:44.323 - info: host.iobroker iobroker Delete adapter "rtspStream.0" 2019-12-31 11:39:44.339 - info: host.iobroker iobroker host.iobroker Counted 1 instances of rtspStream.0 2019-12-31 11:39:44.377 - info: host.iobroker iobroker host.iobroker Counted 1 states of rtspStream.0 2019-12-31 11:39:44.388 - info: host.iobroker iobroker host.iobroker Counted 14 states of system.adapter.rtspStream.0 2019-12-31 11:39:46.124 - info: host.iobroker iobroker host.iobroker Deleting 16 object(s). 2019-12-31 11:39:46.905 - info: host.iobroker object deleted system.adapter.rtspStream.0 2019-12-31 11:39:46.905 - info: host.iobroker stopInstance system.adapter.rtspStream.0 (force=false, process=true) 2019-12-31 11:39:46.909 - info: rtspStream.0 (5753) Got terminate signal TERMINATE_YOURSELF 2019-12-31 11:39:46.906 - info: host.iobroker stopInstance system.adapter.rtspStream.0 send kill signal 2019-12-31 11:39:46.913 - info: Set hostname iobroker for system.adapter.rtspStream.0 2019-12-31 11:39:46.928 - info: host.iobroker stopInstance system.adapter.rtspStream.0 (force=false, process=true) 2019-12-31 11:39:46.931 - info: host.iobroker stopInstance system.adapter.rtspStream.0 send kill signal 2019-12-31 11:39:46.934 - info: rtspStream.0 (5753) Got terminate signal TERMINATE_YOURSELF 2019-12-31 11:39:47.410 - info: rtspStream.0 (5753) terminating 2019-12-31 11:39:47.411 - info: rtspStream.0 (5753) Terminated (START_IMMEDIATELY_AFTER_STOP): Without reason 2019-12-31 11:39:47.907 - info: host.iobroker stopInstance system.adapter.rtspStream.0 killing pid 5753 2019-12-31 11:39:47.914 - info: host.iobroker iobroker exit 0 -
@ilovegym bekannt. Siehe weiter oben. Wird in der 2.2.4 gefixt werden.
-
So, passend zum Jahresende hätte ich hier noch für Euch die 2.2.5 als "Latest RC1"
Änderungen zur 2.2.3 vorher:
- (Apollon77) add certificate handling if a local file is specified and do not overwrite if invalid in
setup first - (Apollon77) add check in objects lib
- (Apollon77) only initialize PacketManager when needed to prevent error messages shown when not relevant
- (Apollon77) change logging when no packetmanageer found to info
- (Apollon77) disable gz-log-rotation on windows; remove added logging from debugging
- (Apollon77) make sure adapters and instances can be deleted again
Mit der Version lass sich Adapter wieder löschen und lokale Zertifikat-Files sollten bei
iobroker cert viewund `setup first bei Updates (@twonky ) wieder tunEs gibt noch ein Known Issue wo wir gerade überlegen wie wir es genau fixen: Man kann aktuell keine "Custom"-Objektsettings (History, iqontrol, telegram ...) mehr deaktivieren/löschen. Das liegt an einem anderen Fix. Wir sind hier noch am Diskutiren wie wir es fixen ... Entweder im Controller ode rim Admin ... Mal schauen.
Dann Happy New Year!
Ingo
- (Apollon77) add certificate handling if a local file is specified and do not overwrite if invalid in
-
-
@apollon77 Danke für die tollen Updates, und auch einen guten Rutsch!
Instanzen lassen sich wieder löschen, super. Soweit läuft das.
-
Klasse Ingo, ich lass das über den Jahreswechsel laufen und checke Moren das Log
Euch allen einen guten Rutsch!
-
Euch auch nen guten Rutsch
-
@apollon77: Das einzige was ich auf dem slave gemacht habe war:
iobroker stop
npm install iobroker.js-controller@2.2.4
iobroker startAuf dem master hatte ich garnichts gemacht. Es sollte doch in keinem Fall der slave Zertifikate des master updaten dürfen oder?
-
@twonky im Controller 2.x haben wir einen Zertifikats Check eingebaut. Der wird bei jedem Controller Update ausgeführt. Egal wo.
Weiterhin: formal gesehen weiß ein Slave nur bedingt das er ein Slave ist. Bei file dBs geht das noch einigermaßen. Bei redis Nutzung ist das eh hinfällig. Daher wird bei einem Controller Update das Zertifikat Objekt gelesen und geprüft .... egal wo das Update läuft.
Aber jetzt mit der 2.2.5 werden file Angaben als User hier geprüft aber nicht geändert.
-
@apollon77 Ich habe nachts nach dem geplanten Neustart des Admin Adapters fast eine Stunde lang Fehlermeldungen:
host.ioBroker 2020-01-01 02:59:00.547 error instance system.adapter.admin.0 terminated with code 156 (156) host.ioBroker 2020-01-01 02:58:01.572 info instance system.adapter.admin.0 started with pid 6569 host.ioBroker 2020-01-01 02:58:00.544 info Restart adapter system.adapter.admin.0 because enabled host.ioBroker 2020-01-01 02:58:00.543 error instance system.adapter.admin.0 terminated with code 156 (156) host.ioBroker 2020-01-01 02:57:01.572 info instance system.adapter.admin.0 started with pid 5870 host.ioBroker 2020-01-01 02:57:00.545 info Restart adapter system.adapter.admin.0 because enabled host.ioBroker 2020-01-01 02:57:00.544 error instance system.adapter.admin.0 terminated with code 156 (156) host.ioBroker 2020-01-01 02:56:01.569 info instance system.adapter.admin.0 started with pid 5237 host.ioBroker 2020-01-01 02:56:00.545 info Restart adapter system.adapter.admin.0 because enabled host.ioBroker 2020-01-01 02:56:00.544 error instance system.adapter.admin.0 terminated with code 156 (156) host.ioBroker 2020-01-01 02:55:01.572 info instance system.adapter.admin.0 started with pid 4550 host.ioBroker 2020-01-01 02:55:00.547 info Restart adapter system.adapter.admin.0 because enabled host.ioBroker 2020-01-01 02:55:00.546 error instance system.adapter.admin.0 terminated with code 156 (156) host.ioBroker 2020-01-01 02:54:11.814 info instance system.adapter.daswetter.0 terminated with code 0 (NO_ERROR) host.ioBroker 2020-01-01 02:54:01.586 info instance system.adapter.admin.0 started with pid 3923 host.ioBroker 2020-01-01 02:54:00.554 info Restart adapter system.adapter.admin.0 because enabled host.ioBroker 2020-01-01 02:54:00.553 error instance system.adapter.admin.0 terminated with code 156 (156) host.ioBroker 2020-01-01 02:54:00.028 info instance system.adapter.daswetter.0 started with pid 3907 host.ioBroker 2020-01-01 02:53:01.582 info instance system.adapter.admin.0 started with pid 3227 host.ioBroker 2020-01-01 02:53:00.553 info Restart adapter system.adapter.admin.0 because enabled host.ioBroker 2020-01-01 02:53:00.553 error instance system.adapter.admin.0 terminated with code 156 (156) host.ioBroker 2020-01-01 02:52:01.583 info instance system.adapter.admin.0 started with pid 2604 host.ioBroker 2020-01-01 02:52:00.555 info Restart adapter system.adapter.admin.0 because enabledIst nichts Dramatisches. Aber das System braucht eben fast 1 Stunde bis es sich wieder gefangen hat.
Ich bin mir aber nicht sicher ob es jetzt am Controler V 2.2.5 oder am Admin V 3.7.5 liegt, da ich blöderweise beie geupdatet habe. -
@Chaot ok. Checke es.
-
@Chaot Ist das log komplett? Hat der Admin adapter zwichendurch nichts gesagt?
-
@apollon77 Nich ganz.
Der Fehler startet mit dem Neustart des Admin Adapters:
Das hat er gestern auch schon gemacht, da habe ich das aber nicht beachtet.
Er hat dann fast eine Stunde gebraucht um sich wieder zu fangen. Den weiteren Tag läuft alles ohne weitere Fehlermeldung. -
@Chaot Ich kann es nicht nachvollziehen
Daher nochmal: Ist das das VOLLE log? nicht irgendwie aussortiert/gefiltert? Ansonsten stehh doch Admin loglevel mal auf debug und schau was nächste nacht im Log steht.Ich vermisse da die ausgaben das Admin sich beendet hat wegen de, Restart und so ...
-
Ansonsten Willkommen im neuen Jahr. Ich habe gerade auf GitHub die 2.2.6 (aka Latest RC2) gestellt, Änderung ist minimal. Es gab ein paar Stellen wo ein Check für den Fall das Die Objects-DB nicht verbunden ist nicht gegriffen haben; das kann beim Stoppen von Adaptern zu crashes desselben führen ...
Have fun!
-
@apollon77 Der zweite gepostete log ist der komplette Bereich ohne Kürzungen.
Der Adapter steht jetzt auf debug. Mal schauen was morgen kommt.
Willst du eventuell den Log von 31.12.auch? -
@Chaot sagte in Beta-Test js-controller 2.2.x GitHub:
Willst du eventuell den Log von 31.12.auch?
wenn der genauso aussieht dann bringt er irgendwie nicht viel ...
Das log würde nahelegen das beim Start von Admin irgendeine ganz generische node exception fliegt. Falls es nochmal passiert müsstest Du mal wach bleiben und genau während der Zeit versuchen den Adapter auf Kommandozeile zu starten das man sehen kann was passiert.
Ich finde es interessant wie schnell die Prozess ID steigt ... An sich wird die mit jedem Prozess um ein erhöht ... bei dir ist hier innerhalb von 60s eine Steigerung von mehreren hundert! ... Strange strange
