Der neue Monatsrückblick für September 2026 ist online!

[mcm1957]

Mit node 24 / npm 11 wird NICHTS geblockt. Da brauchst auch nix freizugeben.
Das sind alles nur npm WARNINGs und die notwendigen Freigaben werden vor node 27 (da wird das Ganze mit npm 12 dann scharf) geeignet erfolgen.

Die Warnings können derzeit einfach ignoriert werden. Und einfach mal alles Scripts ohne Abklärung freizugeben schaltet den sinnvollen zufünftigen nmp Sicherheitsmechanismus aus. Die letzten npm security Vorfälle basierten oft auf eingeschleusten scripts.

[Thomas Braun]

@mcm1957

Kann man das dann als Maintainer des Pakets mitgeben? Ich meine ich hätte da sowas gelesen.

[mcm1957]

oder anders gesagt - sorry wenn ich Thomas widerspreche -

USERn wird von der Verwendung von 'npm install-scripts approve <pkg>' o.ä. dringen ABGERATEN.

Allfällige Anpassungen müssen und werden in den jeweiligen Adaptern vorgenommen. Derzeit wird nichts geblcokt.

[Thomas Braun]

@mcm1957 sagte:

sorry wenn ich Thomas widerspreche -

Nö, ist kein Widerspruch. Hatte doch oben schon ergänzt:

Edit: Soweit ich das verstanden habe wird das aber erst mit npm12 'scharf geschaltet', bei npm 11 ist es zur Zeit nur eine Anzeige und dient zum testen.

[Peter V.]

Danke für eure Infos und Hilfe.
Auch wenn ich jetzt einige Scripte mit "npm install-scripts approve" bearbeitet habe, hoffe ich doch, das jetzt am System nix verbogen ist.
Ansonsten läuft mein Setup ganz zuverlässig.
Die Git installationen sind bis auf einen Adapter (FritzDect) gerade gezogen. Bei dem warte ich jetzt noch, da dort einige spezielle Anpassungen drin sind.
Nochmals Danke ;)

[Thomas Braun]

@Peter-V. sagte:

Auch wenn ich jetzt einige Scripte mit "npm install-scripts approve" bearbeitet habe, hoffe ich doch, das jetzt am System nix verbogen ist.

Da die Meldungen eh zur Zeit für npm 11 ohne Relevanz sind ist da auch nix verbogen. Bis npm12 werden die Pakete vermutlich ohnehin nochmal aktualisiert und fallen wieder in den Sperrzustand zurück.

[Krisiun]

Alles hat super geklappt 👍
Vielen Dank 😊

[Krisiun]

Ich muss mein Kommentar etwas korrigieren ,

Bei mir lief Node.js 24.21.0 grundsätzlich stabil, allerdings ist der RAM-Verbrauch des ioBroker/js-controller deutlich angestiegen. Unter Node 24 lag der Prozess zeitweise bei ca. 1–2 GB RSS. Nach dem Wechsel zurück auf Node 22.23.3 liegt er wieder bei rund 400 MB RSS. Funktionale Probleme hatte ich dabei keine, auffällig war vor allem der deutlich höhere Speicherverbrauch.

[Samson71]

@Krisiun
Das ist nichts neues

https://forum.iobroker.net/topic/85471/steigender-ram-swap-nach-update-auf-nodesjs24

[Krisiun]

@samson71
Sorry wusste ich nicht

[Thomas Braun]

@Krisiun sagte:

auffällig war vor allem der deutlich höhere Speicherverbrauch.

Was aber grundsätzlich kein Fehler oder Problem ist. Hängt halt von der Grundausstattung des Systems ab und wie z. B. dein swap konfiguriert ist.

[bennohaf]

Vielen Dank @tombox . Auch wenn ich keinen Linux Hintergrund habe, habe die v24 ohne Probleme dank deiner Vorgehensweise installiert. Auch merke ich noch keine Performance Probleme mit meinem PI 4 8GB. Danke!

[Krisiun]

@thomas-braun
Danke für die Erklärung. Performance-Probleme hatte ich unter Node 24 ebenfalls nicht. Mein Pi 5 hat 16 GB RAM, Swap wurde nicht benutzt und es waren noch rund 11 GB verfügbar. Auffällig war für mich nur der Unterschied beim js-controller: Unter Node 24.21.0 lag der RSS zeitweise bei ca. 2 GB, nach dem Wechsel zurück auf Node 22.23.3 nach rund 24 Stunden bei ca. 400 MB. Ist so ein Unterschied zwischen Node 22 und 24 aus deiner Sicht noch normal bzw. durch das geänderte Speichermanagement erklärbar?

[Krisiun]

@thomas-braun
Aktueller Vergleichswert unter Node 22.23.3 nach knapp 46 Stunden Laufzeit: js-controller RSS ca. 453 MB, 12 GiB RAM verfügbar, Swap 0 B. Unter Node 24.21.0 lag der js-controller bei mir dagegen zeitweise bei etwa 1–2 GB RSS. Performance-Probleme gab es trotzdem nicht, aber der Unterschied ist deutlich.

[KallAdam]

unter iobroker allgemein im Forum wird noch die 22 Version empfohlen. Ist angeheftet.
https://forum.iobroker.net/category/5/iobroker-allgemein

[Samson71]

@KallAdam
Nicht mehr

[crunchip]

@Krisiun https://forum.iobroker.net/post/1357713 hab hier mal mein Produktivsystem verglichen

[MartinP]

Eine Bemerkung am Rande: Das Verhalten von Node 24 könnte in Leichtsinnig konfigurierten Proxmox Systemen zu Probleme führen.

Das Regularium ist, dass man in Summe seinen gleichzeitig laufenden Containern / Virtuellen Maschinen nur so viel RAM verpassen darf, wie das System hergibt ...

Wenn man da einen Container hinzufügt, muss man anderen Containern RAM abzweigen, wenn man schon alles vergeben hat - da habe ich in der Vergangenheit leider geschludert ...

Beispiel - ich bin so ein Fall der gesagt hat "passt schon" und BISHER damit gut gefahren bin...

PVE: RAM 7,61 GiB, 7,6 GiB Swap

Darunter
Debian Test (LXC) 2+2 GIB
Iobroker (LXC) 6+6 GIB
Fileserver (LXC) 512+512 MiB
Non - Privileged Docker LXC 2 GiB + 512 MiB
Privileged Docker LXC 3 GIB + 512 MiB
OpenCCU VM 2 GiB

Also insgesamt 15,5 GiB zugewiesen, trotzdem nur 8 GIB verfügbar sind ...

Aktuell dümpelt der iobroker LXC bei etwa 2,5 GIB mit Ausschlägen bis 3,5 GiB herum...

Hier noch der PVE

[Samson71]

@MartinP sagte:
Das Regularium ist, dass man in Summe seinen gleichzeitig laufenden Containern / Virtuellen Maschinen nur so viel RAM verpassen darf, wie das System hergibt ...

Muss man nicht aber man sollte schon "sinnvoll überbelegen", d.h. Systeme parallel laufen zu lassen die relativ häufig den max. zugeteilten Speicher auch voll ausnutzen ist sicher nicht gut.
Wer aber ein System mit nur 8GB Speicher quasi komplett doppelt "überbelegt", wo 8GB für einen ioBroker alleine bei dem einen oder anderen System schon manchmal knapp werden können, dem ist - salopp gesagt - aber auch nicht wirklich zu helfen. Das sollte man schon bei der Vergabe im Blick haben.

[crunchip]

@MartinP sagte:

Das Regularium ist, dass man in Summe seinen gleichzeitig laufenden Containern / Virtuellen Maschinen nur so viel RAM verpassen darf, wie das System hergibt ...

falsch, dein Betriebssystem braucht ja auch noch was.

@MartinP sagte:

Also insgesamt 15,5 GiB zugewiesen, trotzdem nur 8 GIB verfügbar sind ...

kann gut gehen, im Zweifelsfall kann es aber sehr dumm laufen