UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[mickym]

@rewenode sagte in Untersuchung: code 25 fehlerlösung:

@mickym Hab grad kein Testsystem und bin froh, das die Updates erstmal gelaufen sind.
Hat sonst noch jemand das Problem dauerhaft lösen können, indem er das nodes_modules Verzeichnis neu aufgebaut hat?

Ja ;) - Natürlich sollte man vorher eine Sicherung machen. Und ich hab den Thread ja unten verlinkt, wo es wunderbar geklappt hat. ;)

[Thomas Braun]

Meine Vermutung ist, das diese temporären Verzeichnisse durch scheiternde Versuche entstehen binäre node-red-Nodes zu bauen.

Die ganzen Verzeichnisse kommen überwiegend aus der node-red-Ecke. Der abbrev-Kram, der oft als erstes auftaucht:

echad@chet:/opt/iobroker $ npm ls abbrev
iobroker.inst@3.0.0 /opt/iobroker
└─┬ iobroker.node-red@4.0.0
  └─┬ node-red@3.0.2
    └─┬ nopt@5.0.0
      └── abbrev@1.1.1

Das würde auch erklären, warum manche wiederkehrend das Problem haben und andere nicht.
gyp kommt nicht zu Ende und die zum bauen verwendeten Verzeichnisse bleiben stehen.

[rewenode]

@mickym @Thomas-Braun
Mal ne ganz dumme Frage eines linux/npm Frischlings.
Hab mir grad mal mein aktuelles node-modules Verzeichnis angesehen.

iobroker@iobroker:~/node_modules$ ls -l
total 3000
drwxr-xr-x  3 iobroker iobroker  4096 Okt  2 21:36 abab
drwxr-xr-x  2 iobroker iobroker  4096 Okt  2 21:36 abbrev
drwxr-xr-x  3 iobroker iobroker  4096 Okt  2 21:36 abort-controller
drwxr-xr-x  2 iobroker iobroker  4096 Okt  2 21:36 accepts
drwxr-xr-x  3 iobroker iobroker  4096 Okt  2 21:36 acme-http-01-standalone
drwxr-xr-x  4 iobroker iobroker  4096 Okt  2 21:36 acorn
drwxr-xr-x  3 iobroker iobroker  4096 Okt  2 21:36 acorn-globals
drwxr-xr-x  3 iobroker iobroker  4096 Okt  2 21:36 acorn-walk
drwxr-xr-x  3 iobroker iobroker  4096 Okt  2 21:36 addressparser
drwxr-xr-x  3 iobroker iobroker  4096 Okt  2 21:36 after
//u.s.w

Das Datum entspricht dem letzten gestrigen Updates egal wie tief ich in die Subverzeichnisse schaue.
Solte das nicht darauf hindeuten, dass jedesmal das komplette node-modules neu aufgebaut wurde?
Dazu würde auch passen, dass das Update (im Vergeleich zu früher) so quälend lang dauert.
Das eigentliche Erstellungsdatum wird bei mir im Container leider nicht gezeigt;-(

iobroker@iobroker:~/node_modules$ stat node-red
  File: node-red
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 801h/2049d	Inode: 12876888    Links: 5
Access: (0755/drwxr-xr-x)  Uid: ( 1000/iobroker)   Gid: ( 1000/iobroker)
Access: 2022-10-02 21:35:28.934884921 +0200
Modify: 2022-10-02 21:36:28.133494430 +0200
Change: 2022-10-02 21:36:28.133494430 +0200
 Birth: -

Egal wo ich schaue Birth: ist immer -

[Thomas Braun]

@rewenode

Du stehst eh im falschen Verzeichnis...

iobroker@iobroker:~/node_modules$

Ist /home/iobroker/node_modules, also das home-Verzeichnis. Der iobroker wohnt aber in /opt/iobroker.

Es sei denn, der node-red-Kram soll da wirklich hin, kann ich mir aber nicht vorstellen.

Solte das nicht darauf hindeuten, dass jedesmal das komplette node-modules neu aufgebaut wurde?

Das wird eh immer gemacht. Dauert halt länger, wenn dann wie ich vermute wieder versucht wird irgendwelche Überbleibsel zu kompilieren.

[rewenode]

@thomas-braun sagte in Untersuchung: code 25 fehlerlösung:

Du stehst eh im falschen Verzeichnis...

Nop, zumindest nicht im Dockercontainer. Auszug aus dem Dockerfile:

# Install ioBroker
RUN curl -sL https://iobroker.net/install.sh | bash - \
    && mkdir -p /opt/scripts/.docker_config/ \
    && echo "starting" > /opt/scripts/.docker_config/.healthcheck \
    && echo "${VERSION}" > /opt/scripts/.docker_config/.thisisdocker \
    && echo $(hostname) > /opt/.firstrun \
    # Deleting UUID from build
    && iobroker unsetup -y \
    # Backup initial ioBroker and userscript folder
    && tar -cf /opt/initial_iobroker.tar /opt/iobroker \
    && tar -cf /opt/initial_userscripts.tar /opt/userscripts \
    # Setting up iobroker-user (shell, home dir and rights)
    && chsh -s /bin/bash iobroker \
    && usermod --home /opt/iobroker iobroker \
    && usermod -u 1000 iobroker \
    && groupmod -g 1000 iobroker \
    && chown root:iobroker /usr/sbin/gosu \
    && chmod +s /usr/sbin/gosu \
    # Clean up installation cache
    && apt-get autoclean -y \
    && apt-get autoremove \
    && apt-get clean \
    && rm -rf /tmp/* /var/tmp/* \
    && rm -rf /root/.cache/* /root/.npm/* \
    && rm -rf /var/lib/apt/lists/*

Zeile 14

reiner@rock64:~$ docker exec -u 1000:1000 -ti iobroker /bin/bash
iobroker@iobroker:~$ pwd
/opt/iobroker
iobroker@iobroker:~$

[rewenode]

@thomas-braun sagte in Untersuchung: code 25 fehlerlösung:

Das wird eh immer gemacht. Dauert halt länger, wenn dann wie ich vermute wieder versucht wird irgendwelche Überbleibsel zu kompilieren.

Ja, deshalb frage ich mich, was es bringen kann, das node-modules Verzeichnis neu aufzubauen.

[Thomas Braun]

@rewenode

Ich hasse diese Docker-Scheisse

[michif100]

@Homoran Also bei mir war das Ganze auch reproduzierbar.
Dank dem Befehl unter

https://forum.iobroker.net/topic/57337/fehler-25-bei-adapter-install-update-mit-npm8/2

konnte ich alle Adapter upgraden, außer NodeRED. Da muss ich mal noch sehen, ob ich noch alte Verzeichnisse finde.

Allerdings zeigt es mir auf der Admin-Oberfläche immer noch an, dass Updates verfügbar wären. Bei der Suche werden dann allerdings keine gelistet:

Zudem kann ein Script wegen fehlender Berechtigung nicht gelöscht werden:

Viele Grüße

[Thomas Braun]

@michif100

iobroker update

sagt? Was in GUIs steht ist oft nicht wahr.

[michif100]

@thomas-braun sagte in Untersuchung: code 25 fehlerlösung:

@michif100

iobroker update

sagt? Was in GUIs steht ist oft nicht wahr.

Passt schon, habe das natürlich mit iobroker update gecheckt, wollte das nur einfach melden, weil im Posting stand, ob es bei uns reproduzierbar ist.
GUI ist klar..

iobroker update
Used repository: stable
Adapter    "admin"        : 6.2.22   , installed 6.2.22
Adapter    "backitup"     : 2.4.12   , installed 2.4.12
Adapter    "discovery"    : 3.0.5    , installed 3.0.5
Adapter    "influxdb"     : 3.1.8    , installed 3.1.8
Adapter    "javascript"   : 6.0.3    , installed 6.0.3
Controller "js-controller": 4.0.23   , installed 4.0.23
Adapter    "loxone"       : 3.0.0    , installed 3.0.0
Adapter    "modbus"       : 5.0.5    , installed 5.0.5
Adapter    "mqtt"         : 4.0.7    , installed 4.0.7
Adapter    "node-red"     : 4.0.0    , installed 4.0.0
Adapter    "proxmox"      : 1.3.4    , installed 1.3.4
Adapter    "shelly"       : 6.0.0    , installed 6.0.0
Adapter    "simple-api"   : 2.7.0    , installed 2.7.0
Adapter    "socketio"     : 4.2.0    , installed 4.2.0
Adapter    "viessmannapi" : 2.0.9    , installed 2.0.9
Adapter    "web"          : 4.3.0    , installed 4.3.0
Adapter    "ws"           : 1.3.0    , installed 1.3.0

Eher störend ist für mich der Fehler beim Löschen des Skripts.

Node ist übrigens v16.15.1

und

npm ist 8.11.0

[Thomas Braun]

@michif100 sagte in Untersuchung: code 25 fehlerlösung:

Node ist übrigens v16.15.1

Updaten.
Den Rest vom Betriebssystem auch.

[Homoran]

@michif100 sagte in Untersuchung: code 25 fehlerlösung:

Adapter "node-red" : 4.0.0 , installed 4.0.0

zur 4.0 gibt es schon Threads

[michif100]

@thomas-braun sagte in Untersuchung: code 25 fehlerlösung:

@michif100 sagte in Untersuchung: code 25 fehlerlösung:

Node ist übrigens v16.15.1

Updaten.

Was habe ich verpasst, ich dachte v16.x sei aktuell die empfohlene Version? Oder liegt es an der Unterversion?

Viele Grüße

[michif100]

@homoran Danke, werde ich mir anschauen

[Thomas Braun]

@michif100

16.17.1 ist aktuell.
Und schau den Rest vom OS auch an.

[michif100]

@thomas-braun OK, danke, werde ich machen.

[rewenode]

@thomas-braun sagte in Untersuchung: code 25 fehlerlösung:

Ich hasse diese Docker-Scheisse

Ich nicht:grin:

[michif100]

@michif100 sagte in Untersuchung: code 25 fehlerlösung:

@thomas-braun sagte in Untersuchung: code 25 fehlerlösung:

@michif100

Adapter "admin" : 6.2.22 , installed 6.2.22
``

Eher störend ist für mich der Fehler beim Löschen des Skripts.

Habe eben noch gelesen unter

https://forum.iobroker.net/topic/58249/skript-löschen-geht-nicht-permissionerror/140?_=1664788908150

dass ein Downgrade auf admin 6.2.12 helfen soll.

[lcars]

Es sollte nichts mit node-red zu tun haben.
Wenn man einen neuen iobroker Container erstellt (docker pull buanet/iobroker) und das ioBroker sich einrichten lässt und das Setup durchklickt, hat man drei Adapter die nicht up to date ist. Wenn man da einen Adapter updaten will kommt auch dieser Fehler 25 und kein Adapter davon ist ein node-red.

D.h. das Problem tritt wohl generell auf und hat wohl imho eher was mit der Node Version oder npm zu tun als bestimmte Adapter.

[Thomas Braun]

@lcars

Kannst du mal die betroffenen Module identifizieren?
Also mit der Variante 'nur-schauen' des Lösch-Skripts.