js-controller 4.0 jetzt im BETA/LATEST!
-
Ich habe testweise mal den tr-064-Adapter eine Versionsnummer zurückgesetzt und anschließend über die Info-Seite wieder auf den aktuellen Stand gebracht. Das hat problemlos funktioniert. Ich habe allerdings den Eindruck, dass die Updates recht lange benötigen.
Falls der Fehler an anderer Stelle nochmal auftritt, sage ich Bescheid und lege ein issue an.
-
@lonsimbt sagte in js-controller 4.0 jetzt im BETA/LATEST!:
Ich habe allerdings den Eindruck, dass die Updates recht lange benötigen.
Denke da musst du npm fragen
-
Habe jetzt auch mal 4.0.10 installiert. System war uptodate
Node.js ist auch richtig/usr/bin/nodejs /usr/bin/node /usr/bin/npm v14.19.0 v14.19.0 6.14.16Bekomme aber folgende Meldungen am Anfang
System startet dann auch und bei beim status kommt folgende Warnung. Kann ich das ignorieren?schlippe@ioBroker-Test:~$ iobroker status (node:15326) Warning: Accessing non-existent property 'count' of module exports inside circular dependency (Use `node --trace-warnings ...` to show where the warning was created) (node:15326) Warning: Accessing non-existent property 'findOne' of module exports inside circular dependency (node:15326) Warning: Accessing non-existent property 'remove' of module exports inside circular dependency (node:15326) Warning: Accessing non-existent property 'updateOne' of module exports inside circular dependency iobroker is running on this host. Objects type: jsonl States type: jsonl -
Ich habe eben nochmal ein Win10 Update gemacht und dann den Broker automatisch neu starten lassen. Dabei poppte die folgende Meldung auf - hatte ich in der Form noch nie und auch die Einstellung 60 Sekunden ließ sich nicht einstellen. Dabei kam die Meldung am unteren Bildrand.
Habe dann Abrechen gedrückt, da ich in der Form eigentlich noch nie Probleme hatte. Waren wohl noch ein paar andere Windows Prozesse im Hintergrund am starten, oder so.....
Das nur mal am Rande.
-
@apollon77
Edit: Sehe gerade im ersten Beitrag, dass die Errors gewollt / ok sind.Ich hab gerade einmal mein Produktivsystem von js-controller 3.3.22 auf 4.0.10 aktualisiert und folgende Ausgabe erhalten:
proxmox@ioBroker:~$ iob stop proxmox@ioBroker:~$ iob upgrade self Update js-controller from @3.3.22 to @4.0.10 NPM version: 6.14.15 npm install iobroker.js-controller@4.0.10 --loglevel error --unsafe-perm --prefi x "/opt/iobroker" (System call) In file included from ../src/unix_dgram.cc:5: ../../nan/nan.h: In function 'void Nan::AsyncQueueWorker(Nan::AsyncWorker*)': ../../nan/nan.h:2294:62: warning: cast between incompatible function types from 'void (*)(uv_work_t*)' {aka 'void (*)(uv_work_s*)'} to 'uv_after_work_cb' {aka ' void (*)(uv_work_s*, int)'} [-Wcast-function-type] 2294 | , reinterpret_cast<uv_after_work_cb>(AsyncExecuteComplete) | ^ In file included from ../../nan/nan.h:56, from ../src/unix_dgram.cc:5: ../src/unix_dgram.cc: At global scope: /home/iobroker/.cache/node-gyp/14.18.2/include/node/node.h:787:43: warning: cast between incompatible function types from 'void (*)(v8::Local<v8::Object>)' to ' node::addon_register_func' {aka 'void (*)(v8::Local<v8::Object>, v8::Local<v8::V alue>, void*)'} [-Wcast-function-type] 787 | (node::addon_register_func) (regfunc), \ | ^ /home/iobroker/.cache/node-gyp/14.18.2/include/node/node.h:821:3: note: in expan sion of macro 'NODE_MODULE_X' 821 | NODE_MODULE_X(modname, regfunc, NULL, 0) // NOLINT (readability/null_ usage) | ^~~~~~~~~~~~~ ../src/unix_dgram.cc:404:1: note: in expansion of macro 'NODE_MODULE' 404 | NODE_MODULE(unix_dgram, Initialize) | ^~~~~~~~~~~ Server Objects 127.0.0.1:59728 Error from InMemDB: Error: GET-UNSUPPORTED for na mespace cfg.: Data=["meta.objects.features.useSets"] Server States 127.0.0.1:34856 Error from InMemDB: Error: GET-UNSUPPORTED for nam espace meta.: Data=["meta.states.protocolVersion"] Server Objects 127.0.0.1:59728 Error from InMemDB: Error: GET-UNSUPPORTED for na mespace cfg.: Data=["meta.objects.protocolVersion"] Server States 127.0.0.1:34858 Error from InMemDB: Error: PSUBSCRIBE-UNSUPPORTED for namespace meta.: Data=["meta.*"] Server Objects 127.0.0.1:59728 Error from InMemDB: Error: Unknown LUA script loa d Server Objects 127.0.0.1:59728 Error from InMemDB: Error: Unknown LUA script loa d Server Objects 127.0.0.1:59728 Error from InMemDB: Error: Unknown LUA script loa d Server Objects 127.0.0.1:59728 Error from InMemDB: Error: SET-UNSUPPORTED for na mespace cfg.: Data=["meta.objects.features.useSets",{"type":"Buffer","data":[49] }] Could not migrate objects to corresponding sets: Error SET-UNSUPPORTED for names pace cfg.: Data=["meta.objects.features.useSets",{"type":"Buffer","data":[49]}] proxmox@ioBroker:~$Nach dem Update ergibt iob status folgendes:
proxmox@ioBroker:~$ iob status iobroker is not running on this host. Objects type: jsonl States type: jsonlproxmox@ioBroker:~$ node -v && nodejs -v && npm -v v14.18.2 v14.18.2 6.14.15 -
@dolomiti bei mir war es mongodb,, die zur gleichen Ausgabe führte
-
@feuersturm sagte in js-controller 4.0 jetzt im BETA/LATEST!:
folgende Ausgabe erhalten:
Wäre da nicht nach dem iob stop ein iob update angebracht gewesen?
-
@dolomiti Das hat nichts mit dem Controller zu tun. Das liegt an Nodejs 14 und scheinbar einer "alten" version von node-red der eine buggy mongodb version enthalten hat und diese verursacht diese Fejhler. ALso bitte node-red aktualisieren
-
@jb_sullivan Diese Meldung kommt vom Admin wenn nicht innerhalb einer definierten Wartezeit Daten kommen. Ja das passiert ggf wenn gerade viele Adapter starten und somit das System unter Last steht.
-
@crunchip sagte in js-controller 4.0 jetzt im BETA/LATEST!:
@feuersturm sagte in js-controller 4.0 jetzt im BETA/LATEST!:
folgende Ausgabe erhalten:
Wäre da nicht nach dem iob stop ein iob update angebracht gewesen?
iob update wurde vor dem iob stop ausgeführt.
-
@feuersturm Sieht alles korrekt aus. Sind die üblichen Compile Warnungen und die oben beschriebenen "einmaligen Not supported "Meldungen. Alles so wie es soll
-
@apollon77 Habe eben unter 4.0.10 5 Adapter aktualisiert (shelly von 5.1.3 auf 5.2.0, text2command von 2.1.2 auf 2.1.6, socketio von 4.1.2 auf 4.1.4, ws von 1.1.4 auf 1.1.6, web von 4.1.4 auf 4.1.5). Als letztes den web und dann kam mal wieder der OOM Killer obwohl die VM nun 6GB hat und nicht über 5 GB belegt hatte:
Also hab ich ein iob stop gemacht und danach ein iob start. Dann kam es zu dem Fall dass Instanzen loopten:
2022-02-17 11:19:11.550 - error: admin.0 (358368) admin.0 already running 2022-02-17 11:19:11.551 - warn: admin.0 (358368) Terminated (ADAPTER_ALREADY_RUNNING): Without reason 2022-02-17 11:19:12.152 - error: host.iobroker instance system.adapter.admin.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING) 2022-02-17 11:19:15.139 - error: email.0 (358380) email.0 already running 2022-02-17 11:19:15.140 - warn: email.0 (358380) Terminated (ADAPTER_ALREADY_RUNNING): Without reason 2022-02-17 11:19:15.739 - error: host.iobroker instance system.adapter.email.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING) 2022-02-17 11:19:19.206 - error: history.0 (358393) history.0 already running 2022-02-17 11:19:19.208 - warn: history.0 (358393) Terminated (ADAPTER_ALREADY_RUNNING): Without reason 2022-02-17 11:19:19.803 - error: host.iobroker instance system.adapter.history.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING) 2022-02-17 11:19:24.000 - error: javascript.0 (358405) javascript.0 already running 2022-02-17 11:19:24.002 - warn: javascript.0 (358405) Terminated (ADAPTER_ALREADY_RUNNING): Without reason 2022-02-17 11:19:24.607 - error: host.iobroker instance system.adapter.javascript.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING) 2022-02-17 11:19:27.671 - error: telegram.0 (358417) telegram.0 already running 2022-02-17 11:19:27.673 - warn: telegram.0 (358417) Terminated (ADAPTER_ALREADY_RUNNING): Without reason 2022-02-17 11:19:28.277 - error: host.iobroker instance system.adapter.telegram.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING) 2022-02-17 11:19:31.374 - error: influxdb.0 (358432) influxdb.0 already running 2022-02-17 11:19:31.375 - warn: influxdb.0 (358432) Terminated (ADAPTER_ALREADY_RUNNING): Without reason 2022-02-17 11:19:31.974 - error: host.iobroker instance system.adapter.influxdb.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING) 2022-02-17 11:19:35.248 - error: alexa2.0 (358444) alexa2.0 already running 2022-02-17 11:19:35.249 - warn: alexa2.0 (358444) Terminated (ADAPTER_ALREADY_RUNNING): Without reason 2022-02-17 11:19:35.848 - error: host.iobroker instance system.adapter.alexa2.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING) 2022-02-17 11:19:39.215 - error: alexa2.1 (358457) alexa2.1 already running 2022-02-17 11:19:39.217 - warn: alexa2.1 (358457) Terminated (ADAPTER_ALREADY_RUNNING): Without reason 2022-02-17 11:19:39.810 - error: host.iobroker instance system.adapter.alexa2.1 terminated with code 7 (ADAPTER_ALREADY_RUNNING) 2022-02-17 11:19:43.691 - info: admin.0 (358468) starting. Version 5.3.0 in /opt/iobroker/node_modules/iobroker.admin, node: v14.19.0, js-controller: 4.0.10 2022-02-17 11:19:43.783 - info: admin.0 (358468) requesting all states 2022-02-17 11:19:43.784 - info: admin.0 (358468) requesting all objects 2022-02-17 11:19:44.134 - info: admin.0 (358468) Request actual repository... 2022-02-17 11:19:45.330 - info: admin.0 (358468) received all objects 2022-02-17 11:19:45.538 - info: admin.0 (358468) https server listening on port 8081 2022-02-17 11:19:45.539 - info: admin.0 (358468) Use link "https://localhost:8081" to configure. 2022-02-17 11:19:46.828 - info: admin.0 (358468) Repository received successfully. 2022-02-17 11:19:47.323 - info: email.0 (358500) starting. Version 1.0.10 in /opt/iobroker/node_modules/iobroker.email, node: v14.19.0, js-controller: 4.0.10 2022-02-17 11:19:47.838 - error: mihome-vacuum.0 (358511) mihome-vacuum.0 already running 2022-02-17 11:19:47.839 - warn: mihome-vacuum.0 (358511) Terminated (ADAPTER_ALREADY_RUNNING): Without reason 2022-02-17 11:19:48.428 - error: host.iobroker instance system.adapter.mihome-vacuum.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING) 2022-02-17 11:19:48.971 - error: admin.0 (358468) error 2022-02-17 11:19:51.615 - error: modbus.0 (358539) modbus.0 already running 2022-02-17 11:19:51.617 - warn: modbus.0 (358539) Terminated (ADAPTER_ALREADY_RUNNING): Without reason 2022-02-17 11:19:52.210 - error: host.iobroker instance system.adapter.modbus.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING) 2022-02-17 11:19:55.302 - error: mqtt.0 (358555) mqtt.0 already running 2022-02-17 11:19:55.303 - warn: mqtt.0 (358555) Terminated (ADAPTER_ALREADY_RUNNING): Without reason 2022-02-17 11:19:55.938 - error: host.iobroker instance system.adapter.mqtt.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING)Also noch mal iob stop, mit ps auxww | grep io geschaut dass nichts mehr läuft und nochmal iob start.
Nun läuft er wieder. Aber dass mit dem OOM Killer seit js-controller 4.x ist schon "interessant". -
@diginix Sehr interessant. Also das "Already running" ist einfach (und da haben Sie auch nicht geloopt!) - Der Restart passiert so schnell das die instanzen noch auf "alive" stehen, das erkennt der startende adapter und sagt "neee, da läuft schon einer". Dann stoppen Sie sich mit Fehler 7, der Controller räumt das auf bzw durch die kurze verzögerung bis zum nächsten Restart ist dann alles ok.
Also wenn ich jetzt frech sein darf frage ich dich ob DU es nachstellen kannst und wenn du es "verlässlich" hinbekommst dann wäre mal eine Idee zurück auf fileDB zu gehen um auszuschliessen das es was mit jsonl zu tun hat
-
@apollon77 sagte in js-controller 4.0 jetzt im BETA/LATEST!:
Die Fehler haben mit Viel-CPU-Problemen nichts zu tun!! Das ist ok so, wundert mich
ging ja nicht um die CPU, sondern die Frage der HOST ERROR MELDUNGEN, bei einem
ìob stop
hier nochmal aus dem daemon.logFeb 16 11:36:06 IoBroker systemd[1]: Stopping ioBroker Server... Feb 16 11:36:08 IoBroker bash[14308]: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason: Feb 16 11:36:08 IoBroker bash[14308]: Error: DB closed Feb 16 11:36:08 IoBroker bash[14308]: at close (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:184:25) Feb 16 11:36:08 IoBroker bash[14308]: at Socket.<anonymous> (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:151:20) Feb 16 11:36:08 IoBroker bash[14308]: at Object.onceWrapper (events.js:520:26) Feb 16 11:36:08 IoBroker bash[14308]: at Socket.emit (events.js:400:28) Feb 16 11:36:08 IoBroker bash[14308]: at Socket.emit (domain.js:475:12) Feb 16 11:36:08 IoBroker bash[14308]: at TCP.<anonymous> (net.js:686:12) Feb 16 11:36:08 IoBroker bash[14308]: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason: Feb 16 11:36:08 IoBroker bash[14308]: Error: DB closed Feb 16 11:36:08 IoBroker bash[14308]: at Redis.sendCommand (/opt/iobroker/node_modules/ioredis/built/redis/index.js:636:24) Feb 16 11:36:08 IoBroker bash[14308]: at Redis.get (/opt/iobroker/node_modules/ioredis/built/commander.js:122:25) Feb 16 11:36:08 IoBroker bash[14308]: at StateRedisClient.setState (/opt/iobroker/node_modules/@iobroker/db-states-redis/lib/states/statesInRedisClient.js:657:40) Feb 16 11:36:08 IoBroker bash[14308]: at Adapter.setState (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/src/lib/adapter/adapter.js:6485:35) Feb 16 11:36:14 IoBroker bash[14308]: ================================== > LOG REDIRECT system.adapter.admin.0 => false [Process stopped] Feb 16 11:36:15 IoBroker bash[14308]: ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] Feb 16 11:36:15 IoBroker bash[14308]: ================================== > LOG REDIRECT system.adapter.javascript.0 => false [Process stopped] Feb 16 11:36:15 IoBroker bash[14308]: ================================== > LOG REDIRECT system.adapter.javascript.0 => false [system.adapter.javascript.0.logging] Feb 16 11:36:16 IoBroker bash[14308]: ================================== > LOG REDIRECT system.adapter.iot.0 => false [Process stopped] Feb 16 11:36:16 IoBroker bash[14308]: ================================== > LOG REDIRECT system.adapter.logparser.0 => false [Process stopped] Feb 16 11:36:16 IoBroker bash[14308]: ================================== > LOG REDIRECT system.adapter.iot.0 => false [system.adapter.iot.0.logging] Feb 16 11:36:16 IoBroker bash[14308]: ================================== > LOG REDIRECT system.adapter.jarvis.0 => false [Process stopped] Feb 16 11:36:17 IoBroker bash[14308]: ================================== > LOG REDIRECT system.adapter.seq.0 => false [Process stopped] Feb 16 11:36:17 IoBroker bash[14308]: ================================== > LOG REDIRECT system.adapter.logparser.0 => false [system.adapter.logparser.0.logging] Feb 16 11:36:17 IoBroker bash[14308]: ================================== > LOG REDIRECT system.adapter.jarvis.0 => false [system.adapter.jarvis.0.logging] Feb 16 11:36:17 IoBroker bash[14308]: ================================== > LOG REDIRECT system.adapter.seq.0 => false [system.adapter.seq.0.logging] Feb 16 11:36:20 IoBroker systemd[1]: iobroker.service: Main process exited, code=exited, status=1/FAILURE Feb 16 11:36:20 IoBroker systemd[1]: iobroker.service: Failed with result 'exit-code'. Feb 16 11:36:20 IoBroker systemd[1]: Stopped ioBroker Server. -
@crunchip Nutzt Du adapter im Compact mode und da in gruppe 0?
EDIT: Ok vergiss die Frage: Diese Logzeilen sind die die der Shelly adapter ausgespuckt hatte nur nochmal "wiederholt"
-
@apollon77 sagte in js-controller 4.0 jetzt im BETA/LATEST!:
@diginix Sehr interessant. Also das "Already running" ist einfach (und da haben Sie auch nicht geloopt!) - Der Restart passiert so schnell das die instanzen noch auf "alive" stehen, das erkennt der startende adapter und sagt "neee, da läuft schon einer". Dann stoppen Sie sich mit Fehler 7, der Controller räumt das auf bzw durch die kurze verzögerung bis zum nächsten Restart ist dann alles ok.
Wenn ich da nicht manuell eingreife geht das munter so weiter. Zumindest war das meine Beobachtung. Da man schnell wieder ein lauffähiges System möchte, bricht man halt mit iob stop alles ab. Ob sich das von allein beruhig hätte, bekommen wir so nicht raus. Eigentlich interessiert mich das OOM Killer "Problem" mehr. Wenn genug da ist, sollte kein Update diesen triggern. Mit js-controller 3.x und file db hatte ich das nie und da war der RAM sogar 2 GG weniger bei identischer Adapter Anzahl.
Also wenn ich jetzt frech sein darf frage ich dich ob DU es nachstellen kannst und wenn du es "verlässlich" hinbekommst dann wäre mal eine Idee zurück auf fileDB zu gehen um auszuschliessen das es was mit jsonl zu tun hat
Verständlich, aber selbst mit Proxmox und VMs ist das keine einfache Aufgabe. Selbst wenn ich die VM klone und darin alles auf file db zurück stelle, kann ich nicht alle Adapter laufen lassen, weil zB mqtt clients nicht an 2 Brokern hängen können. Also liefe im Klon nur ein kleiner Teil der Adapter um auch das Netzwerk nicht zu überlasten. Ob das dann noch repräsentativ wäre, weiß ich nicht. Ich beobachte vorerst mal unverändert weiter.
-
@diginix Ich habe in meinen testsyteme auch rumexperimentiert und bei mir ist RAM technisch alles stabil ...
Die Preisfrage ist ja Wo das RAM verbraucht wird ... (und nur die Grafik darfst nicht ansehen weil Linux sich an sich RAM krallt wenns da ist und freigibt wenn nötig. also "zählt nur" free -m
-
@diginix sagte in js-controller 4.0 jetzt im BETA/LATEST!:
Wenn ich da nicht manuell eingreife geht das munter so weiter. Zumindest war das meine Beobachtung.
sollte maxmial 30s so sein (wenn mehr als einmal)...
-
@apollon77 Vielen Dank. Die kleine Änderung am Code hat mir sehr geholfen.
-
@diginix Kannst du mal mitschneiden, was die einzelnen ioBroker-Prozesse an RAM verbrauchen? Z.B. durch History-Aufzeichnung von
system.adapter.<adaptername>.0.memRssundsystem.host.<hostname>.memRssEbenfalls interessant wäre (einmalig) Anzahl Objekte, Anzahl States und input/output count der Adapter.
