NEWS
Test js-controller v2.0.x (GitHub)
-
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg SOrry, aber warum kommt Ihr immer auch solche Ideen wie "audit fix" ... Ich weiss das npm das als Info ausgibt, aber es ist einfach in meinen Augen nur gefährlich
Es mag auch vllt mit komplett firschen installatioen seit ein paar Monaten funktionieren, aber effektiv besteht das grosse Risiko das danach nichts mehr tut Und dann zu helfen ist gelinde gesagt nahezu unmöglichIch kann immer nur von meiner Situation ausgehen und gebe ganz bewusst keine Anleitung dazu. Falls Verschlimmbesserung oder what else = Snapshot
Risiko besteht natürlich immer, dann dürfte ich aber auch hier beim Beta Test nicht mitmachen. Ich erinnere nur an den letzten Test der 1.5er, die in einer Version den Broker zerschoss, da hilft dann das Backup -
@SBorg Aus meiner Sicht ist
audit fix
unnötig und gefährlich. Es versucht, Abhängigkeiten zu updaten ohne dass man weiß, dass Kompatibilität besteht.Daher werde ich die Meldung in der nächsten Installer/Fixer-Version deaktivieren, damit man überhaupt nicht auf die Idee kommt, das auszuführen.
-
Das steht im Fixer? Ist mir noch nie aufgefallen *ups*
-
@SBorg Nein. Aber damit habe ich die Möglichkeit, diese Option von npm auszuschalten.
-
kurze Rückmeldung.
Mein Multihost System läuft jetzt komplett auf 2.0.9. Objekte und neuerdings auch Files laufen auf redis.
Auch das reconnect der Slave nach einem Neustart des Masters funktionirt einwandfrei.
Ich musste allerdings den js.controller mit dem Befehlsudo -H -u iobroker npm install ioBroker/ioBroker.js-controller
installieren. Egal ob root oder normaler user, auch der fixer brachte keine besserung.
Alle Adapter sind grün, bis jetzt konnte ich keine Fehler feststellen.
Mir ist aufgefallen, das laut Anzeige 19 "vis" Instanzen installiert sind.
-
@SBorg Die Fragfe war auch eher allgemein und rethorisch gemeint weil viele Leute das tun (und mit 1.5.x getan haben und so ...) ... ;-))
-
@e-i-k-e sagte in [Aufruf] js-controller 2.0 Beta Test:
Mein Multihost System läuft jetzt komplett auf 2.0.9. Objekte und neuerdings auch Files laufen auf redis.
Wie waren die Meldungen bei den "iobroker setup custom"? War das alles eindeutig und korrekt - vor allem auch wegen Master und Slave und so? Konntest Du nichts falsch machen oder gab es Punkte wo du bange hattest? Real user Feedback ist da cool.
Mir ist aufgefallen, das laut Anzeige 19 "vis" Instanzen installiert sind.
lol ... legst Du dazu bitte mal ein GitHub Issue im js-controller an? Muss ich ansehen. kann es stimmen wenn du alle Vis-Widget und Icons und so noch dazurechnest? also alles was mit vis beginnt? Wäre meine Vermutung -
@e-i-k-e sagte in [Aufruf] js-controller 2.0 Beta Test:
Egal ob root oder normaler user, auch der fixer brachte keine besserung.
Was war denn die Fehlermeldung wenn du das nicht mit sudo ausgeführt hast?
-
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
also alles was mit vis beginnt? Wäre meine Vermutung
Wäre auch meine. Also Regex-Test mit
/^vis./
anstatt/^vis\./
-
@AlCalzone oder es ist in getInstances und damit unterschied wegen "Redis" oder so ...
-
bekomme folgende Fehlermeldung im Log:
host.iObroker 2019-09-25 12:50:19.577 error Caught by controller[0]: .0: ../deps/uv/src/unix/poll.c:123: uv_poll_start: Assertion `!(((handle)->flags & (UV_HANDLE_CLOSING | UV_HANDLE_CLOSED)) != 0)' failed.
-
@watcherkb Ich denke wir benötigen etwas mehr Kontext. Stürzt ein Adapter ab?
-
@AlCalzone sorry...hier nochmal detaillierter: ich habe ein Testsystem aufgesetzt und dort mein Backup vom Livesystem eingespielt. Alle Adapter bis auf den radar2 sind deaktiviert. Fehler kommt auch erst, wenn ich den radar2 Adapter starte. Vielleicht hat das ja auch mit dem eigentlich Update von js nichts zu tun.
host.iObroker 2019-09-25 13:20:01.382 info Restart adapter system.adapter.radar2.0 because enabled host.iObroker 2019-09-25 13:20:01.382 info instance system.adapter.radar2.0 terminated with code NaN () host.iObroker 2019-09-25 13:20:01.381 warn instance system.adapter.radar2.0 terminated due to SIGABRT host.iObroker 2019-09-25 13:20:01.381 error Caught by controller[0]: .0: ../deps/uv/src/unix/poll.c:123: uv_poll_start: Assertion `!(((handle)->flags & (UV_HANDLE_CLOSING | UV_HANDLE_CLOSED)) != 0)' failed. radar2.0 2019-09-25 13:20:01.208 info (2382) debug: radar2 received undefined objects and 1 states, with config devices,scandelay,arp_scan_cmd,btadapterid,printerdelay,debug,knownIPs,knownBTs,external,delayaway,delayuwz,numuwz,hcionly,l2 radar2.0 2019-09-25 13:20:01.148 info (2382) starting. Version 1.2.0 in /opt/iobroker/node_modules/iobroker.radar2, node: v10.16.3 radar2.0 2019-09-25 13:20:00.793 debug (2382) States connected to redis: 127.0.0.1:6379 radar2.0 2019-09-25 13:20:00.787 debug (2382) statesDB connected radar2.0 2019-09-25 13:20:00.784 debug (2382) Objects connected to redis: 127.0.0.1:9001 radar2.0 2019-09-25 13:20:00.782 debug (2382) Redis States: Use Redis connection: 127.0.0.1:6379 radar2.0 2019-09-25 13:20:00.780 debug (2382) objectDB connected radar2.0 2019-09-25 13:20:00.731 debug (2382) Redis Objects: Use Redis connection: 127.0.0.1:9001 host.iObroker 2019-09-25 13:20:00.059 info instance system.adapter.radar2.0 started with pid 2382 host.iObroker 2019-09-25 13:20:00.037 info "system.adapter.radar2.0" enabled host.iObroker 2019-09-25 13:20:00.036 info object change system.adapter.radar2.0 (from: system.adapter.admin.0)
-
@AlCalzone sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg Nein. Aber damit habe ich die Möglichkeit, diese Option von npm auszuschalten.
Danke, dachte schon bin blind. Im Alter weiß man ja nie... ^^
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg Die Fragfe war auch eher allgemein und rethorisch gemeint weil viele Leute das tun (und mit 1.5.x getan haben und so ...) ... ;-))
Alles gut ...und ich teste gerne.
Jetzt müsste man nur noch wissen woran es liegt -
Ich muss gestehen, dass mein English nicht das Beste ist und ich deswegen übersetzen musste. Danach waren mir die Meldungen klar.
Die erste Frage war glaube ich: " Es wurde automatisch erkannt das dieser Host ein Slave ist, ist das korrekt? Y/N (oder so ähnlich).
Dies wurde mir auch auf dem Master so angezeigt. Vieleicht wäre es einfacher zu fragen, ob dieser Host ein Master oder Slave ist.Zu Vis, Jackpot!
Sind genau 19 Instanzen die mit Vis anfangen Zudem fehlen die Icon ("iobroker update all" wurde natürlich ausgeführt). -
npm install ioBroker/ioBroker.js-controller
pi@raspberrypi-slave:~ $ iobroker stop pi@raspberrypi-slave:~ $ cd /opt/iobroker pi@raspberrypi-slave:/opt/iobroker $ npm install ioBroker/ioBroker.js-controllernpm ERR! code EPERM npm ERR! syscall spawn npm ERR! errno EPERM npm ERR! Error: spawn EPERM npm ERR! at ChildProcess.spawn (internal/child_process.js:366:11) npm ERR! at spawn (child_process.js:551:9) npm ERR! at execFile (child_process.js:221:15) npm ERR! at tryCatcher (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23) npm ERR! at ret (eval at makeNodePromisifiedEval (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:16:23) npm ERR! at promiseRetry (/usr/lib/node_modules/npm/node_modules/pacote/lib/util/git.js:192:14) npm ERR! at /usr/lib/node_modules/npm/node_modules/promise-retry/index.js:29:24 npm ERR! { Error: spawn EPERM npm ERR! at ChildProcess.spawn (internal/child_process.js:366:11) npm ERR! at spawn (child_process.js:551:9) npm ERR! at execFile (child_process.js:221:15) npm ERR! at tryCatcher (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23) npm ERR! at ret (eval at makeNodePromisifiedEval (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:16:23) npm ERR! at promiseRetry (/usr/lib/node_modules/npm/node_modules/pacote/lib/util/git.js:192:14) npm ERR! at /usr/lib/node_modules/npm/node_modules/promise-retry/index.js:29:24 npm ERR! cause: npm ERR! { Error: spawn EPERM npm ERR! at ChildProcess.spawn (internal/child_process.js:366:11) npm ERR! at spawn (child_process.js:551:9) npm ERR! at execFile (child_process.js:221:15) npm ERR! at tryCatcher (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23) npm ERR! at ret (eval at makeNodePromisifiedEval (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:16:23) npm ERR! at promiseRetry (/usr/lib/node_modules/npm/node_modules/pacote/lib/util/git.js:192:14) npm ERR! at /usr/lib/node_modules/npm/node_modules/promise-retry/index.js:29:24 errno: 'EPERM', code: 'EPERM', syscall: 'spawn' }, npm ERR! stack: npm ERR! 'Error: spawn EPERM\n at ChildProcess.spawn (internal/child_process.js:366:11)\n at spawn (child_process.js:551:9)\n at execFile (child_process.js:221:15)\n at tryCatcher (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23)\n at ret (eval at makeNodePromisifiedEval (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:16:23)\n at promiseRetry (/usr/lib/node_modules/npm/node_modules/pacote/lib/util/git.js:192:14)\n at /usr/lib/node_modules/npm/node_modules/promise-retry/index.js:29:24', npm ERR! errno: 'EPERM', npm ERR! code: 'EPERM', npm ERR! syscall: 'spawn', npm ERR! parent: 'iobroker' } npm ERR! npm ERR! The operation was rejected by your operating system. npm ERR! It is likely you do not have the permissions to access this file as the current user npm ERR! npm ERR! If you believe this might be a permissions issue, please double-check the npm ERR! permissions of the file and its containing directories, or try running npm ERR! the command again as root/Administrator. npm ERR! A complete log of this run can be found in: npm ERR! /home/pi/.npm/_logs/2019-09-25T17_19_35_938Z-debug.log
sudo -H -u iobroker npm install ioBroker/ioBroker.js-controller
pi@raspberrypi-slave:/opt/iobroker $ sudo -H -u iobroker npm install ioBroBroker.js-controller > iobroker.js-controller@2.0.9 preinstall /opt/iobroker/node_modules/iobro-controller > node lib/preinstallCheck.js NPM version: 6.11.3 > iobroker.js-controller@2.0.9 install /opt/iobroker/node_modules/iobrokerntroller > node iobroker.js setup first npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.0.7 (node_modulvents): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fse2.0.7: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":) npm WARN optional SKIPPING OPTIONAL DEPENDENCY: osx-temperature-sensor@1.0de_modules/osx-temperature-sensor): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for osxrature-sensor@1.0.4: wanted {"os":"darwin","arch":"any"} (current: {"os":","arch":"arm"}) + iobroker.js-controller@2.0.9 updated 3 packages and audited 1656 packages in 87.662s found 14 vulnerabilities (9 low, 5 high) run `npm audit fix` to fix them, or `npm audit` for details
-
Nach einem Neustart des Masters, blieben einige Adapter gelb/rot.
Erst nachdem ich einen manuellen Neustart der Adapter durchgeführt , wurden diese grün.Anbei das log. iobroker.2019-09-25.log
Neustart Master ~19.00 Uhr
Neustart der gelb/roten Adapter: ~19.37Uhr -
@e-i-k-e ich denke, warum auch immer, das das nur ein Anzeigeproblem im Admin ist.
Zum verifizieren:
Nach dem Start wenn eine solche Instanz gelb ist:- „iobroker state get Adapter.0.info.connection“ aufrufen. Ist val auf true??
- wenn ja bitte in Admin gehen und unter Objekte auch bis zu dem info.connection durchklicken. Steht da true?
- jetzt auf Instanzen zurück ... wird jetzt grün angezeigt?
-
@e-i-k-e Update all ??or upload all?? Letzteres wäre das korrekte
Zur Anzahl Instanzen; ich checke. Vllt hat es such was mit dem info connection zu tun
-
@apollon77 natürlich Upload all