js-controller 6.0.x jetzt für alle User im STABLE!

[fellpower]

@codierknecht
Also fassen wir zusammen:

Ich habe den js-controller geupdatet, das hat wohl funktioniert.
Aufgrund der Docker "Problematik" kann ich mein node.js irgendwie nicht updaten.

Wenn ich es mit den bekannten Befehlen versuche (Wie hier beschrieben: https://forum.iobroker.net/topic/64032/update-nodejs-best-practise-supported-16-und-18), dann funktioniert das irgendwie nicht. node.js bleibt auf 18.20.4.

Also muss ich warten, bis buanet was neues bringt - oder selbst n Container bauen, wäre noch ne Möglichkeit.

Was ist mit den Node-Red Fehlern auf dem Bild? Woher kommen die - und wie löse ich das?

[crunchip]

@fellpower sagte in Nach Update des JS Controllers einige Fehler:

Also muss ich warten, bis buanet was neues bringt?

https://github.com/buanet/ioBroker.docker/releases/tag/v10.0.0-beta.1

[fellpower]

@crunchip
Hab ich schon gesehen. Wollte aber warten, bis nicht mehr Beta.

Aber ich denke, dann ist ja eigentlich alles richtig gelaufen, nur node.js kann noch nicht geupdatet werden, bis ich das Image neu ausrolle.

Was sind das für Fehler mit Node-Red? Weiß das jemand? Node-Red an sich funktioniert noch.

[crunchip]

@fellpower sagte in Nach Update des JS Controllers einige Fehler:

Was sind das für Fehler mit Node-Red?

stimmt wohl die Verlinkung nicht

[foxriver76]

@crunchip Docker oder klassische Linux Installation?

[crunchip]

@foxriver76

@crunchip sagte in js-controller 6.0.x jetzt für alle User im STABLE!:

buanet-docker Installation image - v9.1.2

[foxriver76]

@crunchip Hm okay.. vor den Fehlern im Screenshot sieht man da noch andere Fehler? Im Endeffekt kann er bei setup first entweder nicht zur DB verbinden oder es kommt vorher zu einem Fehler den man auf dem Screenshot nicht sieht.

[foxriver76]

@ofbeqnpolkkl6mby5e13 Und beim Neustart von javascript treten die Fehler erneut auf oder in welchem Interval, weil du meintest es hat aufgehört?

[crunchip]

@foxriver76 ich kann da nicht scrollen, da das Bild dann eingefroren ist, oben im ersten Beitrag ist das log eingefügt

[foxriver76]

@crunchip Okay, kannst du mal inventwo vorher stoppen und dann nochmal probieren, iwie überlebt der den terminate Prozess ist auch etwas was mit dem nächsten Controller nochmal optimiert wurde aber mit 5.0.19 eben noch nicht.

[oFbEQnpoLKKl6mbY5e13]

@foxriver76

Meine Einschätzung ist, dass für jeden Alias mit Konvertierungsfunktion die Meldung einmal vom Javascript-Adapter kommt und einmal vom Influxdb-Adapter, wenn derselbe Alias zusätzlich auch protokolliert wird. Da ich sehr viele Alias mit Konvertierungsfunktion habe, sah es aus, als wenn da wiederholt "Millionen" Meldungen durchlaufen. Es waren auch sehr viele, aber wie bereits erwähnt, nur einmal bzw. zweimal pro Alias. Ein Neustart des Javascript-Adapters bringt die Meldungen nicht erneut hervor.

[MartinP]

Was sagt mir die Meldung

"... Body has already been consumed?"

Bei mir läuft gerade das Update aus der GUI

[foxriver76]

@martinp Mit welcher Admin Version? Grundsätzlich ein Fehler im Admin aber sollte mit aktueller stable (7.0.22) eigentlich nicht mehr auftreten.

[foxriver76]

@ofbeqnpolkkl6mby5e13 Hm okay, falls es bei controller neustart wieder auftritt gib bitte Bescheid, ansonsten weiß ich gerade nicht wie ich es nachgestellt bekomme.

[oFbEQnpoLKKl6mbY5e13]

@foxriver76

Okay.

[MartinP]

@foxriver76 Aktuell ist die Kiste noch mitten im Update Prozess, kann ich nicht beantworten. Ist aber eigentlich auf dem aktuellen Stable-Stand (Keine Hinweise auf Updates)

[foxriver76]

@martinp ist auch erst seit heute morgen oder gestern Abend stable also könnte sein, dass es ohne manuelles aktualisieren nocht niocht aufgepoppt ist.

[crunchip]

@foxriver76 sagte in js-controller 6.0.x jetzt für alle User im STABLE!:

kannst du mal inventwo vorher stoppen und dann nochmal probieren, iwie überlebt der den terminate Prozess

hab ich vorher gestoppt, trotzdem bei upgrade, irgendwie seltsam

2024-08-02 09:22:49.895  - info: admin.0 (150) ==> Connected system.user.admin from ::ffff:10.1.1.129
2024-08-02 09:23:23.143  - info: host.IoBroker "system.adapter.vis-inventwo.0" disabled
2024-08-02 09:23:23.143  - info: host.IoBroker stopInstance system.adapter.vis-inventwo.0 (force=false, process=true)

2024-08-02 09:25:05.288  - info: host.IoBroker [CONTROLLER_AUTO_UPGRADE] Successfully stopped js-controller
2024-08-02 09:25:05.290  - info: host.IoBroker [CONTROLLER_AUTO_UPGRADE] Server is running on http://localhost:8081
2024-08-02 09:25:14.298  - info: host.IoBroker force terminating
2024-08-02 09:25:14.299  - info: host.IoBroker Adapter vis-inventwo still running
2024-08-02 09:25:19.287  - error: vis-inventwo.0 (1494) Objects database error: connect ECONNREFUSED 127.0.0.1:9001
2024-08-02 09:25:19.301  - error: vis-inventwo.0 (1494) States database error: connect ECONNREFUSED 127.0.0.1:9000
2024-08-02 09:25:24.290  - error: vis-inventwo.0 (1494) Objects database error: connect ECONNREFUSED 127.0.0.1:9001
2024-08-02 09:25:24.301  - error: vis-inventwo.0 (1494) States database error: connect ECONNREFUSED 127.0.0.1:9000
2024-08-02 09:25:29.292  - error: vis-inventwo.0 (1494) Objects database error: connect ECONNREFUSED 127.0.0.1:9001
2024-08-02 09:25:29.303  - error: vis-inventwo.0 (1494) States database error: connect ECONNREFUSED 127.0.0.1:9000

[MartinP]

@foxriver76 Jetzt ist der Update einigermaßen durch. Admin war vorher noch auf 6.xxx, wird gerade auf die 7er Version aktualisiert

[foxriver76]

@crunchip hm mal stoppen und den Prozess per cli abschießen, iwie möchte der sich nicht beenden lassen.

Vorher im ioBroker den Adapter deaktivieren
ps -aux | grep io.vis-inventwo die erste Zahl nach dem User Namen ist die PID
dann kill -9 <pid>

dann nochmal das ps Kommando um sicherzustellen dass der Prozess weg ist, aber wenn er in ioB deaktiviert ist sollte niemand ihn neustarten. Dann nochmal probieren.

Aber echt merkwürdig..

Im Zweifel würde ich das offizielle Docker Image klassisch updaten und mit Controller v6 sollten auch solche hartnäckigen Fälle gekillt werden.