npm prune schlägt fehl wegen iobroker.objects-redis

[dQeLse]

@thomas-braun ja redis wird verwendet.
so wie ich es vestanden habe, wird objects-redis vom js-controller bereitgestellt, ich hatte nie dieses verzeichnis.
Daher wunder ich mich woher npm die Information nimmt...

[Homoran]

@dqelse was sagt iobroker status ?

[dQeLse]

@homoran

iobroker@cerberus:/opt/iobroker$ iobroker status
iobroker is running on this host.

At least one iobroker host is running.

Objects type: redis
States  type: redis

[Homoran]

@dqelse das ist nicht das interne redis sondern die Datenbank für states und bei dir sogar für Objekte

[dQeLse]

@homoran d.h.? muss ich die objects-redis per hand installieren? weil das repo existiert ja nicht mehr und ist in iobroker.db enthalten.

[Homoran]

@dqelse sagte in npm prune schlägt fehl wegen iobroker.objects-redis:

weil das repo existiert ja nicht mehr

welches repo?

die Meldung mit dem package-lock hat ichts mit deiner redis db zu tun

mit Package lock haben zur Zeit einige User Probleme.
Eine allgemeingültige Lösung oder gar Ursache habe ich noch nicht gesehen.

Hattest du mal mit root gearbeitet?

[dQeLse]

@homoran nein ich arbeite nur als normaler User und sudo wenn nötig

ich meinte dieses repo https://github.com/foxriver76/ioBroker.objects-redis

[Thomas Braun]

@dqelse

Das Modul ist ja wohl Bestandteil des js-controllers. Hast du den mal neu 'drüber' installiert?

[dQeLse]

@thomas-braun habe ich probiert, geht aber auch nicht wegen genau diesem problem

iobroker@cerberus:/opt/iobroker$ iobroker upgrade self --force --debug
Update js-controller from @4.0.23 to @4.0.23
Stopped Objects DB
Stopped States DB
NPM version: 8.11.0
Installing iobroker.js-controller@4.0.23... (System call)
npm WARN skipping integrity check for git dependency ssh://git@github.com/xXBJXx/ioBroker.fully-tablet-control.git
npm WARN tarball tarball data for iobroker.objects-redis@file:iobroker.objects-redis (null) seems to be corrupted. Trying again.
npm WARN tarball tarball data for iobroker.objects-redis@file:iobroker.objects-redis (null) seems to be corrupted. Trying again.
npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142
npm ERR! code ENOENT
npm ERR! syscall open
npm ERR! path /opt/iobroker/iobroker.objects-redis/package.json
npm ERR! errno -2
npm ERR! enoent ENOENT: no such file or directory, open '/opt/iobroker/iobroker.objects-redis/package.json'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/iobroker/.npm/_logs/2022-06-21T10_20_32_799Z-debug-0.log
host.cerberus Cannot install iobroker.js-controller@4.0.23: 254

mikeal created this issue in request/request

open Request’s Past, Present and Future #3142

[dQeLse]

So, habe wieder einen Downgrade auf die v14.19.3 gemacht, sowie das Repo auf stable umgestellt.
npm prune läuft wieder ohne Probleme durch, auch die package.json und die -lock werden erstellt.
ebenso zur Sicherheit den JS nochmal neuinstalliert, aber das iobroker.objects-redis verzeichnis wird auch unter der v14. nicht erstellt, allerdings findet man in der packages.json folgendes:

   "node_modules/iobroker.objects-redis": {
      "resolved": "file:node_modules/iobroker.objects-redis/iobroker.objects-redis"
    },

jetzt stellt sich die Frage warum das bei v14 funzt aber bei der v16 nicht?

[Homoran]

@dqelse sagte in npm prune schlägt fehl wegen iobroker.objects-redis:

das bei v14 funzt aber bei der v16 nicht?

weil npmv8 anders tickt

[dQeLse]

nun läuft es bei mir, ich habe eine Neuinstallation unter v16 durchgeführt und das ging ohne Probleme.
Vielen Dank für eure Hilfe, aber wahrscheinlich wahr bei mir in der Installation was zerstrubbelt.

[Homoran]

@dqelse sagte in npm prune schlägt fehl wegen iobroker.objects-redis:

aber wahrscheinlich wahr bei mir in der Installation was zerstrubbelt.

sieht so aus.

Bisher haben alle, die so (massive) Probleme nach dem upgrade hatten, nach einem Restore in einer frischen Basis keine Probleme mehr gehabt.

Frage:
hattest du irgendwann als root oder bei npm mit sudo gearbeitet?

[dQeLse]

hmm kann vielleicht ganz am anfang gewesen sein, aber nicht das ich mich erinnern kann.
was mich allerdings auch stutzig machte, das bei mir alles abhängigkeiten zu iobroker.inst@2.0.2 hatte.
ist halt ne ältere installation bei der ich immer brav die updates per web ausser dem JS per konsole machte.

[Homoran]

@dqelse danke!
ich hatte (habe) in den Threads mit den Problemen den Eindruck gewonnen, dass mit npm v8 das rooten härter bestraft wird.
Das würde ich gerne festigen oder ausschließen.

[dQeLse]

@homoran ich habe zu danken

[crunchip]

@homoran sagte in npm prune schlägt fehl wegen iobroker.objects-redis:

Das würde ich gerne festigen oder ausschließen.

meinst du,
generell mit root arbeitet / hatte, oder unter root mal irgendwo "falsch abgebogen ist"

wenn mein iobroker ohne den üblichen Problemen wie ble, zigbee... danach ohne Probleme funktioniert, kannste es ausschließen da ich immer noch mit root unterwegs bin.
Update Session aller Maschinen hatte ich gestern und alles auf Stand gebracht.
Werde demnächst doch mal umstellen, dann sehen wir es ja

[Homoran]

@crunchip sagte in npm prune schlägt fehl wegen iobroker.objects-redis:

oder unter root mal irgendwo "falsch abgebogen ist"

das will ich gerade herausfinden.

Ich weiß ja auch nicht wer jetzt für die Fehlersuche ganz schnell sich des möglichen Anschisses besinnt und flugs doch den user für's Protokoll nimmt.

Außerdem traue ich dir zu das sudo bei npm korrekt anzuwenden.

aber es geht nur um die node16 npm8 Problematik bei diesen Usern

[seb]

Ich hatte gerade ähnliche Probleme beim Umstieg auf node 16. Bei mir hat es gereicht, das Paket zu deinstallieren, also:

npm uninstall iobroker.objects-redis

Ich hab dann sicherheitshalber noch ein

npm cache clean --force
npm install

gemacht, aber ich denke, das war gar nicht nötig.

Danach konnte ich wieder Adapter updaten.