31 Dec 2019, 14:20
Beta-Test js-controller 2.2.x GitHub
-
@Einstein67 sagte in Beta-Test js-controller 2.2.x GitHub:
Die Logs sehen nicht so schlecht aus. Allerdings ist, im Vergleich zu den Logs von vor 2 Tagen, nun auch eine Fehlermeldung vorhanden: "ERROR: No packet manager found"
Web-GUI - Entfernen einer Instanz
$ ./iobroker del info.0 Delete adapter "info.0" host.iob10b Counted 1 instances of info.0 host.iob10b Counted 1 devices of info.0 host.iob10b Counted 58 channels of info.0 ERROR: No packet manager found host.iob10b Counted 294 states of info.0 host.iob10b Counted 14 states of system.adapter.info.0 host.iob10b Deleting 368 object(s). host.iob10b: Only 200 objects left to be deleted. process exited with code 0Web-GUI - Adapter löschen
$ ./iobroker del info Delete adapter "info" host.iob10b Counted 1 instances of info host.iob10b Counted 1 adapter for info ERROR: No packet manager found host.iob10b Deleting 2 object(s). npm uninstall iobroker.info --silent --save --prefix "/opt/iobroker" (System call) process exited with code 0Danach öffnet sich in beiden Fällen die AdapterKonfiguration ....
Was mir noch aufgefallen ist: Das entfernen von Adaptern/Instanzen funktioniert mittels Konsole auch nur dann, wenn ioBroker vorher gestoppt wurde!
Konsole - ioBroker läuft. Instanz wird nicht gelöscht (nach starten ist nach einiger Zeit der Adapter auch wieder da)
iobroker@iob10b:~$ iobroker del info Delete adapter "info" host.iob10b Counted 1 instances of info host.iob10b Counted 1 adapter for info host.iob10b Counted 1 devices of info host.iob10b Counted 58 channels of info host.iob10b Counted 294 states of info host.iob10b Counted 14 states of system.adapter.info host.iob10b Deleting 369 object(s). No packet manager found host.iob10b: Only 200 objects left to be deleted. npm uninstall iobroker.info --silent --save --prefix "/opt/iobroker" (System call)Konsole - ioBroker gestoppt und trotz der Fehlermeldung am Ende, wird die Instanz und der Adapter entfernt.
iobroker@iob10b:~$ iobroker stop iobroker@iob10b:~$ iobroker del info Delete adapter "info" host.iob10b Counted 1 instances of info host.iob10b Counted 1 adapter for info host.iob10b Counted 1 devices of info host.iob10b Counted 58 channels of info host.iob10b Counted 294 states of info host.iob10b Counted 14 states of system.adapter.info No packet manager found host.iob10b Deleting 369 object(s). host.iob10b: Only 200 objects left to be deleted. npm uninstall iobroker.info --silent --save --prefix "/opt/iobroker" (System call) Cannot write files: /opt/iobroker/iobroker-data/files/info.admin/_data.json: ENOENT: no such file or directory, open '/opt/iobroker/iobroker-data/files/info.admin/_data.json'Kann ich ebenfalls so bestätigen ...
-
So, ich denke ich hab das Problem mit dem Adapter löschen gefunden. Eine Sache ist noch offen die ich mit Bluefox klären muss - es ist noch was mit den History/Custom-Einstellungen im Argen.
Eine 2.2.5 vllt morgen oder Neujahr dann :-))
-
Die Reconnect Probleme im Multihost ist mit der Version 2.2.4 behoben.
Ich habe master auf 2.1.1 und slave auf 2.2.4. Wenn der master neustartet verbinden sie die slaves nun wieder korrekt.
-
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.
-
Neuschwansteini Forum Testing Most Active last edited by Neuschwansteini 31 Dec 2019, 10:41 31 Dec 2019, 10:33
@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 ...
