ioBroker hängt sich immer wieder mal auf

Chief42

Systemdata	Proxmox VM
Hardwaresystem:	ZBOX CI331 nano (Celeron N5100)
Arbeitsspeicher:	4GB (der VM zugewiesen)
Festplattenart:	virtuell (SSD, Partion für ioBroker = 32GB)
Betriebssystem:	Debian 11
Nodejs-Version:	v20.2.0
NPM-Version:	v9.6.6
Installationsart:	nach Anleitung (https://www.iobroker.net/#de/documentation/install/proxmox.md) Debian + ioBroker per "curl -sLf https://iobroker.net/install.sh bash -"

Hallo zusammen!

Seit etwa zwei Monaten, den genauen Zeitpunkt kann ich nicht nennen, hängt sich mein ioBroker zu unterschiedlichen Tageszeiten immer wieder mal auf.

Einen Zusammenhang mit einem Adapter oder einem Script kann ich nicht erkennen aber ist auch nicht auszuschließen. Ich hatte schon die zuletzt installierten Adapter deaktiviert aber das hat nichts gebracht. Im Logfiles vom ioBroker, die Stufe steht auf Debug, kann ich auch nichts auffälliges erkennen. Die Logfiles der Debian-Installation und von Proxmox geben imho auch keine hilfreichen Hinweise.

Auffällig ist, dass die CPU bei dem Fehler dauerhaft auf ca. 50% läuft (ein CPU-Limit ist nicht eingestellt):

ÜbersichtProxmox.jpg

Wenn der Fehler auftritt kann man den ioBroker nicht mehr erreichen (Ping, Telnet, Web, Konsole über Proxmox).

Das Logfile vom ioBroker hatte gestern zuletzt diese Einträge:

2023-07-16 14:49:28.636 - info: daikin-cloud.0 (569) Wert_vor_Veröffentlichung_enfternt: Cloud connection status changed to false - Reinitialize all Objects
2023-07-16 14:49:28.637 - info: daikin-cloud.0 (569) Initialize device Wert_vor_Veröffentlichung_enfternt: connected false, lastUpdated Invalid Date
2023-07-16 14:49:54.194 - info: admin.0 (443) Request actual repository...
2023-07-16 14:49:54.198 - debug: host.iobroker Incoming Host message getRepository
2023-07-16 14:49:54.291 - info: host.iobroker Updating repository "stable" under "http://download.iobroker.net/sources-dist.json"
2023-07-16 14:49:56.661 - info: admin.0 (443) Repository received successfully.
2023-07-16 14:50:28.884 - info: daikin-cloud.0 (569) Wert_vor_Veröffentlichung_enfternt: Cloud connection status changed to true - Reinitialize all Objects
2023-07-16 14:50:28.884 - info: daikin-cloud.0 (569) Initialize device Wert_vor_Veröffentlichung_enfternt: connected true, lastUpdated Invalid Date
2023-07-16 15:06:33.124 - info: daikin-cloud.0 (569) Wert_vor_Veröffentlichung_enfternt: Cloud connection status changed to false - Reinitialize all Objects
2023-07-16 15:06:33.125 - info: daikin-cloud.0 (569) Initialize device Wert_vor_Veröffentlichung_enfternt: connected false, lastUpdated Invalid Date
2023-07-16 15:10:34.207 - info: daikin-cloud.0 (569) Wert_vor_Veröffentlichung_enfternt: Cloud connection status changed to true - Reinitialize all Objects
2023-07-16 15:10:34.207 - info: daikin-cloud.0 (569) Initialize device Wert_vor_Veröffentlichung_enfternt: connected true, lastUpdated Invalid Date
2023-07-16 15:12:34.879 - info: daikin-cloud.0 (569) Daikin-Cloud tokens updated ...
2023-07-16 15:12:34.889 - info: daikin-cloud.0 (569) Daikin-Cloud tokens updated ...
2023-07-16 15:12:35.016 - info: daikin-cloud.0 (569) Daikin-Cloud tokens updated ...
2023-07-16 15:12:35.021 - info: daikin-cloud.0 (569) Daikin-Cloud tokens updated ...
2023-07-16 15:19:37.248 - info: daikin-cloud.0 (569) Wert_vor_Veröffentlichung_enfternt: Cloud connection status changed to false - Reinitialize all Objects
2023-07-16 15:19:37.249 - info: daikin-cloud.0 (569) Initialize device Wert_vor_Veröffentlichung_enfternt: connected false, lastUpdated Invalid Date
2023-07-16 15:22:37.829 - info: daikin-cloud.0 (569) Wert_vor_Veröffentlichung_enfternt: Cloud connection status changed to true - Reinitialize all Objects
2023-07-16 15:22:37.830 - info: daikin-cloud.0 (569) Initialize device Wert_vor_Veröffentlichung_enfternt: connected true, lastUpdated Invalid Date
2023-07-16 15:24:38.303 - info: daikin-cloud.0 (569) Wert_vor_Veröffentlichung_enfternt: Cloud connection status changed to false - Reinitialize all Objects
2023-07-16 15:24:38.304 - info: daikin-cloud.0 (569) Initialize device Wert_vor_Veröffentlichung_enfternt: connected false, lastUpdated Invalid Date
2023-07-16 15:25:38.641 - info: daikin-cloud.0 (569) Wert_vor_Veröffentlichung_enfternt: Cloud connection status changed to true - Reinitialize all Objects
2023-07-16 15:25:38.641 - info: daikin-cloud.0 (569) Initialize device Wert_vor_Veröffentlichung_enfternt: connected true, lastUpdated Invalid Date

Syslog

Jul 16 12:17:01 iobroker CRON[4094638]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul 16 13:17:01 iobroker CRON[4161767]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul 16 14:17:01 iobroker CRON[35224]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul 16 15:08:14 iobroker systemd[1]: Starting Cleanup of Temporary Directories...
Jul 16 15:08:14 iobroker systemd[1]: systemd-tmpfiles-clean.service: Succeeded.
Jul 16 15:08:14 iobroker systemd[1]: Finished Cleanup of Temporary Directories.
Jul 16 15:17:01 iobroker CRON[102408]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul 17 08:59:25 iobroker kernel: [    0.000000] Linux version 5.10.0-23-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 2021>
Jul 17 08:59:25 iobroker kernel: [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-23-amd64 root=UUID=60204c76-925b-4cfc-8718-0d62b002f7f>
Jul 17 08:59:25 iobroker kernel: [    0.000000] x86/fpu: x87 FPU will use FXSAVE

Die VM des ioBrokers habe ich auch auch schon testweise auf einen anderen Proxmox Host laufen lassen (aus Backup wiederhergestellt). Da tritt das gleiche Problem auf. Also kann man den Proxmox-Host vermutlich ausschließen.

Updates (Debian VM, Proxmox, ioBroker Adapter) sind nach dem vorletzten Absturz auch installiert worden, hat nichts an dem Problem geändert.

Neben dem ioBroker läuft in der VM noch dieses Wetterstationsscript: https://forum.iobroker.net/topic/28384/linux-shell-skript-wlan-wetterstation

Empfohlen wird ja aktuell noch die Version Nodejs 18. Ich habe allerdings, aufgrund der Probleme, scheinbar unbewusst irgendwann mal die 20 installiert. Ich meine mich allerdings zu erinnern, dass das Problem auch mit einer älteren Version auftrat.

Hat jemand eine Idee wo ich noch ansetzen könnte?
Gibt es noch andere Logfiles die man auswerten kann?
Hat das Problem evtl. sogar schonmal jemand gehabt und eine Lösung zur Hand (die ich über die Suche nicht gefunden habe)?

Vielen Dank für die Unterstützung und viele Grüße
Chief42

bahnuhr

@chief42

Momentan sind wir bei nodejs 18
Warum hast du nodejs 20 ?

Du bist mit Sicherheit nicht nach Anleitung vorgegangen.

Gehe wieder auf 18.

iob diag
wäre auch interessant

Thomas Braun

@chief42 sagte in ioBroker hängt sich immer wieder mal auf:

Ich habe allerdings, aufgrund der Probleme, scheinbar unbewusst irgendwann mal die 20 installiert.

Mit nodejs@20 gibt es noch ganz andere Probleme. Von der empfohlenen Version abzuweichen ist nicht sinnvoll.
Geh auf nodejs@18 zurück.

Chief42

@bahnuhr
@thomas-braun

Vielen Dank für die schnellen Antworten!

Wie gesagt, ich habe nicht vorsätzlich eine nicht unterstützte Version installiert. Wegen der Probleme ist vermutlich die neuere Version irgendwo angezeigt wurden und ich habe dann wohl zu schnell auf OK geklickt. Wenn man bisher nichts mit dem ioBroker und Linux zu tun hatte ist das schon ein recht komplexes System.

Die Grundinstallation wurde 1:1 mit der Anleitung gemacht und wenn ich mich nicht sehr irre gab es auch keine unklaren Punkte oder Fehlermeldungen.

Ich habe die Version 20 scheinbar erfolgreich deinstallieren können. Ich hoffe das passt jetzt. Bei der Deinstallation gab es jedoch ein paar Warnungen:

Möchten Sie fortfahren? [J/n] j
Holen:1 https://deb.nodesource.com/node_18.x bullseye/main amd64 nodejs amd64 18.16.1-deb-1nodesource1 [28,7 MB]
Es wurden 28,7 MB in 3 s geholt (11,5 MB/s).
dpkg: Warnung: Version 20.2.0-deb-1nodesource1 des Paketes nodejs wird durch ältere Version 18.16.1-deb-1nodesource1 ersetzt
(Lese Datenbank ... 51109 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../nodejs_18.16.1-deb-1nodesource1_amd64.deb ...
Entpacken von nodejs (18.16.1-deb-1nodesource1) über (20.2.0-deb-1nodesource1) ...
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/wrap-ansi/node_modules/emoji-regex« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/wrap-ansi/node_modules« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/wrap-ansi« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/path-scurry/node_modules/lru-cache« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/path-scurry/node_modules« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/path-scurry« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/node-gyp/node_modules/signal-exit« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/jackspeak« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/foreground-child« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/cross-spawn/node_modules/which« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/cross-spawn/node_modules« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/cross-spawn« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/@tufjs/models« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/@tufjs/canonical-json« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/@tufjs« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/@sigstore/protobuf-specs« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/@sigstore« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/@pkgjs/parseargs« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/@pkgjs« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/@isaacs/cliui/node_modules/emoji-regex« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/@isaacs/cliui/node_modules« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
dpkg: Warnung: Altes Verzeichnis »/usr/lib/node_modules/npm/node_modules/@isaacs/cliui« kann nicht gelöscht werden: Das Verzeichnis ist nicht leer
nodejs (18.16.1-deb-1nodesource1) wird eingerichtet ...
Trigger für man-db (2.9.4-2) werden verarbeitet ...

Ein kurzer stichprobenartiger Check ergab, dass das irgendwelche Lizenzinfos sind. Ich denke das stört nicht, oder?

Die Diagnose bringt keine (für mich) offensichtlichen Fehler. Hier die Zusammenfassung:

======================= SUMMARY =======================
                     v.2023-04-16


Operatingsystem:        Debian GNU/Linux 11 (bullseye)
Kernel:                 5.10.0-23-amd64
Installation:           kvm
Timezone:               Europe/Berlin (CEST, +0200)
User-ID:                0
X-Server:               false
Boot Target:            graphical.target

Pending OS-Updates:     0
Pending iob updates:    0

Nodejs-Installation:    /usr/bin/nodejs         v18.16.1
                        /usr/bin/node           v18.16.1
                        /usr/bin/npm            9.5.1
                        /usr/bin/npx            9.5.1

Recommended versions are nodejs 18.x.y and npm 9.x.y
Your nodejs installation is correct

MEMORY:
               total        used        free      shared  buff/cache   available
Mem:            3.9G        1.2G        1.7G        0.0K        1.1G        2.5G
Swap:           974M          0B        974M
Total:          4.9G        1.2G        2.6G

Active iob-Instances:   17
Active repo(s): stable

ioBroker Core:          js-controller           4.0.24
                        admin                   6.3.5

ioBroker Status:        iobroker is running on this host.


Objects type: jsonl
States  type: jsonl

Status admin and web instance:
+ system.adapter.admin.0                  : admin                 : iobroker                                 -  enabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin

Objects:                5597
States:                 4873

Size of iob-Database:

11M     /opt/iobroker/iobroker-data/objects.jsonl
5.9M    /opt/iobroker/iobroker-data/states.jsonl



=================== END OF SUMMARY ====================

Ich werde das mal eine Weile bobachten und berichten. Das kann allerdings, wenn es "schlecht" läuft, 2 bis 3 Wochen dauern bis sich die Kiste wieder aufhängt.

Thomas Braun

@chief42

Hampel da nicht als root herum. Gerade nicht als Linux-Anfänger.

Chief42

@thomas-braun

Root ist auf dem System deaktiviert, zumindest gehe ich davon aus das ich das richtig gemacht habe. Der einzige angelegte User hat auch keine Root-Rechte (sofern das der richtige Befehl zum Auslesen der Rechte ist):

iobroker@iobroker:/opt/iobroker$ groups
iobroker tty dialout cdrom floppy sudo audio dip video plugdev netdev

Ich hatte das downgrade mit "sudo -i" ausgeführt weil es dauernd irgendwelche Berechtigungsprobleme mit "sudo ..." gab. Damit lief es dann ohne Fehler durch. Normalerweise "hampel" ich dort, auch wenn man meine Linuxversuche durchaus als "hampeln" bezeichnen kann, nicht als root herum. Ich wüsste auch nicht wie ich sonst etwas deinstallieren oder installieren kann.

DJMarc75

@chief42 als User "iobroker" macht das auch nicht grad besser, denn der User ist halt eigentlich vom System schon "vergeben"
Erstell einen anderen User mit den bekannten Befehlen.

Thomas Braun

@chief42

User-ID:                0

ist der root.

Thomas Braun

@chief42 sagte in ioBroker hängt sich immer wieder mal auf:

Ich hatte das downgrade mit "sudo -i" ausgeführt weil es dauernd irgendwelche Berechtigungsprobleme mit "sudo ..." gab.

Ich weiß nicht was du warum da mit sudo -i machst, aber es ist falsch. Darauf deutet auch deine Aussage 'weil es dauernd irgendwelche Berechtigungsprobleme mit "sudo ..." gab.' hin.
In einem unverfummelten System gibt es da nicht 'irgendwelche Berechtigungsprobleme'. Außer selber von dir eingeschleppte.

Chief42

@djmarc75
Also in der Anleitung für die Debian Installation unter Proxmox steht nicht, dass man den Benutzernamen "iobroker" nicht nehmen darf/soll. Wenn man dann unkreativ ist und sich nicht auskennt nimmt man dann halt iobroker. Da bin ich sicher nicht der Erste der das gemacht hat ;) . Wenn das doch irgendwo stehen sollte habe ich es nicht gesehen. Allerdings weiß ich auch, dass man auch schon aus Sicherheitsgründen einen anderen User nehmen sollte...

@thomas-braun
In der Anleitung zum Downgrade (https://forum.iobroker.net/topic/35090/howto-nodejs-installation-und-upgrades-unter-debian) wird das auch mit sudo gemacht. Also kann sudo im allgemeinen ja nicht das Problem bzw. falsch sein.

Eine Googlesuche zu dem Fehler den es gab führte mich zu sudo -i (den Parameter kannte ich bis dahin nicht) . Welcher Fehler das genau war kann ich nicht mehr sagen. Das habe ich nicht abgespeichert, da wurde irgendwas nicht gefunden.

Wenn ich die Diagnose in einer neuen Session laufen lasse kommt

Operatingsystem:        Debian GNU/Linux 11 (bullseye)
Kernel:                 5.10.0-23-amd64
Installation:           kvm
Timezone:               Europe/Berlin (CEST, +0200)
User-ID:                1000
X-Server:               false
Boot Target:            graphical.target

Also lag die User-ID 0 daran, dass ich das in der Session habe laufen lassen, die ich mit sudo -i gestartet hatte die ich zu dem Zeitpunkt noch nicht mit "exit" beendet hatte.

Die ID 0 wird übrigens auch angezeigt,. wenn ich "sudo iob diag" aufrufe (was man normalerweise sicher nicht macht):

Operatingsystem:        Debian GNU/Linux 11 (bullseye)
Kernel:                 5.10.0-23-amd64
Installation:           kvm
Timezone:               Europe/Berlin (CEST, +0200)
User-ID:                0
X-Server:               false
Boot Target:            graphical.target

Ich will nicht ausschließen das etwas eingeschleppt oder verbogen ist aber bewusst/absichtlich wurde da sicher nichts verbogen. Gerade weil ich mich mit Linux nicht auskenne habe ich das alles auf Standard gelassen, abgesehen von den Konfigurationen die durchgeführt werden sollten.

Thomas Braun

@chief42 sagte in ioBroker hängt sich immer wieder mal auf:

In der Anleitung zum Downgrade (https://forum.iobroker.net/topic/35090/howto-nodejs-installation-und-upgrades-unter-debian) wird das auch mit sudo gemacht. Also kann sudo im allgemeinen ja nicht das Problem bzw. falsch sein.

Die Anleitung kenne ich, die ist von mir...
Natürlich müssen Pakete mit root-Rechten / per sudo eingespielt werden. Das ist ja Sinn und Zweck der Trennung von root-Rechten zu einem Standard-User, der das eben nicht darf.

Die ID 0 wird übrigens auch angezeigt,. wenn ich "sudo iob diag" aufrufe (was man normalerweise sicher nicht macht):

Auch das ist mir bekannt, das Skript ist ja auch von mir. Und NEIN, man ruft möglichst wenig mit sudo auf, weil das direkt dann halt mit den Rechten des root läuft. Denn:

echad@chet:/opt/iobroker $ whoami
echad
echad@chet:/opt/iobroker $ sudo whoami
root
echad@chet:/opt/iobroker $

Und weil das so ist braucht man auch nie eine root shell.

Notiz an mich selbst:
Code, der eine Ausführung als root verhindert, wieder scharf schalten...

DJMarc75

@chief42 sagte in ioBroker hängt sich immer wieder mal auf:

in der Anleitung für die Debian Installation unter Proxmox steht nicht

hat ja auch rein nichts mit iobroker zu tun.

Chief42

@djmarc75 sagte in ioBroker hängt sich immer wieder mal auf:

@chief42 sagte in ioBroker hängt sich immer wieder mal auf:

in der Anleitung für die Debian Installation unter Proxmox steht nicht

hat ja auch rein nichts mit iobroker zu tun.

Nach welcher Anleitung, außer dieser hier https://www.iobroker.net/#de/documentation/install/proxmox.md, soll der Anfänger denn vorgehen? Da steht nichts zum Usernamen drin.

@thomas-braun
Ich glaube ich habe deutlich erklärt, dass ich noch die Session mit sudo -i offen hatte in der ich das Script aufgerufen hatte. Mir ist schon klar das man sudo im Normalfall nicht braucht/nutzt und das ist auch keine Ursache/Lösung zu dem Problem.

Der Fehler trat heute übrigens wieder auf. Da ich aber die nächsten Antworten, die hier kommen werden, aus den bisherigen ableiten kann versuche das Problem lieber selbst zu lösen.

Danke für die Unterstützung.

guergen

@chief42 Die Problematik mit dem Absturz kenne ich. Kommt mal mehr, mal weniger oft vor.
Manchmal rödelt der Admin Ewigkeiten, dann geht es plötzlich wieder.
Andersmal hängt sich die VM im Proxmox weg, sodass noch nicht einmal ein Reboot, sonden ein Stop unter Proxmox helfen muss.
Leider bin ich auch noch nicht dem Problem auf die Schliche gekommen, könnte mir aber Proxmox als Ursache dazu vorstellen: Nach dem Upgrade auf die 8er Proxmox-Version und Bookworm in der VM waren die Fehler wieder häufiger.
Zwei bis Dreimal die Woche trifft es mich ;-)

Nein, ich bin nicht als root unterwegs!
Sondern immer schon als "iob".

Thomas Braun

@chief42 sagte in ioBroker hängt sich immer wieder mal auf:

Mir ist schon klar das man sudo im Normalfall nicht braucht/nutzt

Und warum machst du es dann wider bessern Wissens doch?

und das ist auch keine Ursache/Lösung zu dem Problem.

Das ist deine Behauptung/Vermutung, meine Erfahrung ist, das solche 'verrooteten' Kisten an allen möglichen Stellen komisch ticken können.

crunchip

@chief42 sagte in ioBroker hängt sich immer wieder mal auf:

Da steht nichts zum Usernamen drin

Werd ich ergänzen

Edit:
erledigt

? Offline

@guergen sagte in ioBroker hängt sich immer wieder mal auf:

Leider bin ich auch noch nicht dem Problem auf die Schliche gekommen, könnte mir aber Proxmox als Ursache dazu vorstellen: Nach dem Upgrade auf die 8er Proxmox-Version und Bookworm in der VM waren die Fehler wieder häufiger.

Moin,

da legst Du Dich aber sehr weit aus dem Fenster ;)

Ich habe Proxmox seit Version 6.2 oder so am Laufen, sowohl die Migration zu 7 als auch zur 8er verliefen ohne Probleme, zu dem laufen auch alle LXC Container stabil, da ist ein Zoo von 3x Debian und 6x Arch Linux als Gast OS im Container am Laufen.

Ich vermute, dass Du Dein Proxmox, und die darin laufenden VMs, LXC Container falsch konfiguriert hast, z.B.: zu viel Speicher verteil, der gar nicht physikalisch da ist, Dir kann man aber nicht helfen, ohne, dass Du hier handfeste Informationen lieferst.
Also nicht nur Behauptungen äußern, sondern die Fehler oder seine Installation zeigen.

VG
Bernd

crunchip

@dp20eic sagte in ioBroker hängt sich immer wieder mal auf:

sowohl die Migration zu 7 als auch zur 8er verliefen ohne Probleme

bei mir nicht ganz, bzw es läuft, aber bei einem Node von dreien, hab ich seit v8 nen Serverlast anstieg von 1
vorher lag ich im Schnitt bei 0.4, jetzt bei 1,4

selbst wenn ich alle Maschinen stoppe bleibt es bestehen, finde allerdings die Ursache nicht, aber ist hier OT

Chief42

@crunchip sagte in ioBroker hängt sich immer wieder mal auf:

@chief42 sagte in ioBroker hängt sich immer wieder mal auf:

Da steht nichts zum Usernamen drin

Werd ich ergänzen

Edit:
erledigt

Ich installiere die Kiste neu auch wenn sie nicht "verrootet" ist. Ich vermute, dass sich Adapter und/oder Blockly-Scripte in die Quere kommen. Evtl. fahre ich auch parallel und verschiebe die Adapter/Scripte nacheinander auf den neuen ioBroker um dem Problem auf die Spur zu kommen.

Bei der Installation von Debian habe ich aber eben noch nicht den Hinweis auf den Usernamen "iobroker" gesehen. Evtl habe ich es auch überlesen aber es geht um diese Stelle:

(Ja, mir ist klar dass man das nicht im Screenshot ändern kann.)

Weiter oben im Text stand dazu nichts.

Diesen Hinweis "ACHTUNG! - Es darf kein root Passwort vergeben werden." hatte ich beachtet. Es ging darum, dass man den Usernamen "iobroker" nicht nehmen darf.

@djmarc75 sagte in ioBroker hängt sich immer wieder mal auf:

s User "iobroker" macht das auch nicht grad besser, denn der User ist halt eigentlich vom System schon "vergeben"
Erstell einen anderen User mit den bekannten Befehlen.

Hardware-Ressourcen sind bei mir übrigens reichlich vorhanden und es wurde auch kein Over-Provisioning eingerichtet.

Homoran

@chief42 sagte in ioBroker hängt sich immer wieder mal auf:

Weiter oben im Text stand dazu nichts.

@chief42 sagte in ioBroker hängt sich immer wieder mal auf:

Es ging darum, dass man den Usernamen "iobroker" nicht nehmen darf.

sollte!

einige User nutzen (leider) iobroker als ihren Usernamen.
frag mich nicht warum, aber es scheint zu klappen.

Noch besser ist, wenn der Hostname auch noch iobroker ist
iobroker@iobroker

Community Forum

NEWS

ioBroker hängt sich immer wieder mal auf

Support us

335

32.5k

81.8k

1.3m