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

[Happyuser20]

iobroker (6).html iobroker (5).html Hallo zusammen,

ich habe seit Kurzem ein Problem mit meiner ioBroker-Installation auf einer Synology DS218+.

Die Installation lief zuvor etwa 66 Tage ohne Probleme durch. Seit dem 8. Oktober 2026 ist der js-controller jedoch mehrfach mit einem Core Dump abgestürzt.

Ich versuche herauszufinden, ob der Fehler mit einem kürzlich durchgeführten Admin-Update, der Docker-Umgebung oder Node.js zusammenhängt.

1. Fehlermeldung

Im Docker-Protokoll erscheint vor dem Absturz:

iobroker.js-controller:
../deps/uv/src/unix/linux.c:1430:
uv__io_poll:
Assertion `errno == EEXIST' failed.

Anschließend:

/opt/scripts/iobroker_startup.sh: line 591:
Aborted (core dumped)
gosu iobroker node node_modules/iobroker.js-controller/controller.js

Der Fehler trat beispielsweise zu folgenden Zeitpunkten auf:

• 08.10.2026, ca. 12:34 Uhr
• 08.10.2026, 18:43 Uhr

Die Fehlermeldung ist bei beiden Abstürzen identisch.

2. Systemkonfiguration

Komponente	Version / Hardware
NAS	Synology DS218+
Prozessor	Intel Celeron J3355, 2 Kerne
RAM	16 GB
DSM	7.3.2
Linux-Kernel	4.4.302+
Docker-Image	buanet/iobroker:v11.1.0
Node.js	22.23.2
js-controller	7.2.2
Admin-Adapter	8.0.14
Objects-Datenbank	JSONL
States-Datenbank	JSONL
ioBroker-Hosts	Master auf Synology, Slave auf Raspberry Pi

Die Installation umfasst ungefähr 35 aktive Adapterinstanzen sowie rund 36.700 Objekte und 31.500 States.

3. Änderungen kurz vor den ersten Abstürzen

Es gab zwei wesentliche Änderungen.

A. Update des Admin-Adapters

Zunächst war Admin 8.0.11 installiert.

Nach dem Update auf 8.0.14 wurde die neue Version offenbar nicht korrekt übernommen. Obwohl die Installation durchgeführt wurde, zeigte ioBroker weiterhin Version 8.0.11 an.

Nach dem ersten Absturz und einem Neustart des Docker-Containers wurde mir das Update auf 8.0.14 erneut angeboten.

Dieses Mal wurde es installiert und anschließend auch korrekt angezeigt.

Ich vermute deshalb, dass der erste Updateversuch möglicherweise nicht sauber abgeschlossen wurde.

B. Installation und intensive Nutzung von Paperless-NGX

Auf derselben Synology wurde außerdem Paperless-NGX mit PostgreSQL, Redis, Tika und Gotenberg installiert.

In den vergangenen Tagen wurden viele Dokumente importiert und die automatische Zuordnung eingerichtet.

Paperless verwendet außerdem ein eigenes Python-Post-Consume-Skript zur Metadatenverarbeitung.

Mir ist aufgefallen, dass Dokumentenimporte teilweise relativ lange dauern.

Im Leerlauf liegt die CPU-Auslastung von Paperless allerdings nur bei etwa 0,5 %. Ob während der OCR-Verarbeitung kurzfristig hohe Systemlast entsteht, wurde noch nicht abschließend untersucht.

4. Auffällige CPU-Auslastung des js-controllers

Bei unseren Untersuchungen fiel auf, dass der js-controller über längere Zeit relativ viel CPU-Leistung benötigt.

Beispielwerte:

iobroker.js-controller: 44,7 % CPU
io.javascript.0:       5,3 % CPU
io.upnp.0:             4,0 % CPU
io.shelly.0:           3,5 % CPU

Eine spätere Momentanmessung des Controllers ergab:

43,8 %
30,5 %
27,0 %

Der gesamte ioBroker-Docker-Container lag zeitweise bei etwa 76–89 % CPU, später allerdings nur noch bei ungefähr 23 %.

5. Datenbanken

Die Installation verwendet JSONL für Objects und States.

Bei einer Messung wuchs states.jsonl innerhalb von 30 Sekunden von 17,6 MB auf 19,3 MB.

Eine anschließende Prüfung ergab:

JSONL-Zeilen:       111954
Gültige Zeilen:     111954
Ungültige Zeilen:   0

Die JSONL-Datei enthält also zumindest keine erkennbaren Syntaxfehler.

Das konfigurierte Schreibintervall beträgt 30 Sekunden für States und 5 Sekunden für Objects.

6. Bereits durchgeführte Maßnahmen

• Ein veraltetes VIS-1-Projekt mit zahlreichen Meldungen vom Typ Invalid group id wurde aus dem Projektverzeichnis entfernt und gesichert.
• Danach waren zunächst keine weiteren entsprechenden Meldungen im Docker-Protokoll sichtbar.
• Der js-controller stürzte jedoch weiterhin mit der genannten libuv-Assertion ab.
• Die ioBroker-Datenbanken wurden überprüft, aber nicht verändert.
• Es wurden bislang keine Adapter zur Fehlersuche deaktiviert.
• Node.js, Docker-Image und js-controller wurden noch nicht gewechselt.

7. Meine Fragen

1. Ist die Fehlermeldung uv__io_poll: Assertion errno == EEXIST failed in Verbindung mit dem js-controller 7.2.2 und Node.js 22 bekannt?
2. Gibt es bekannte Probleme mit Admin 8.0.14, insbesondere nach einem möglicherweise unvollständig durchgeführten Update?
3. Könnte die Kombination aus Node.js 22, Docker und dem älteren Synology-Kernel 4.4.302+ eine Rolle spielen?
4. Kann eine hohe Belastung durch andere Docker-Container, beispielsweise Paperless-OCR, einen solchen Fehler auslösen oder begünstigen?
5. Wäre ein Test mit einer anderen Node.js-Version oder einem anderen Docker-Image sinnvoll? Welche Kombination wäre mit js-controller 7.2.2 empfehlenswert?
6. Gibt es eine Möglichkeit, zusätzliche Debug-Informationen oder einen aussagekräftigen Stacktrace zu erhalten, um den eigentlichen Auslöser zu identifizieren?

Ich möchte möglichst vermeiden, die komplette ioBroker-Installation neu aufzusetzen, da zahlreiche Automatisierungen, Adapter und VIS-Projekte eingerichtet sind.

Über Hinweise zur weiteren systematischen Fehlersuche würde ich mich freuen.

Vielen Dank im Voraus!

Thread erstellt mit Chatgpt

Anbei noch die Log Files der letzten beiden abstürze.
iobroker (6).html
iobroker (5).html

[crunchip]

KI sagt:
Abstürze am 08.10.2026:
12:34:19 und 18:43:16 jeweils uv__io_poll: Assertion 'errno == EEXIST' failed, danach Aborted (core dumped) beim js-controller (PIDs 248 / 250). Direkt davor steht in den Logs kein JS-Stack — nur die libuv-Zeile. Die eigentliche Ursache lässt sich so nicht einem Adapter zuordnen; dafür bräuchtest du einen ausgewerteten Core Dump oder kurz vorher strace am Controller-Prozess.

Technik (kurz): Das ist ein libuv-/epoll-Abbruch in Node: epoll_ctl schlägt fehl, libuv erwartet nur errno == EEXIST, sonst abort(). Bekanntes Muster in Node/libuv (z. B. nodejs/node#63308); ein Fix in Node ist nicht zuverlässig verfügbar. Kein heap out of memory in deinen Logs — das wäre ein anderer Absturztyp.

Wichtig aus den Logs (Nebenbefunde):

12:36:58 (nach dem ersten Crash): weatherunderground — Connection is closed / unbehandelte Promise. Das wirkt wie Folge des Neustarts, nicht wie Auslöser ~2 Minuten nach der Assertion.
17:47 vor dem zweiten Crash: wieder viele Invalid group id (VIS) plus Diag — u. a. 71 Instanzen, Admin 8.0.14, paperless-ngx 1.0.2, zwei Hosts mit 7.2.2. In (6).html allein >12.000 Zeilen mit Invalid group id — VIS ist in diesem Zeitraum noch stark im Log.
Täglich 06:05: TypeError in Alexa_SSML-Bloecke_erzeugen (null.length, unbehandelte Promise) — separat fixen (try/catch / null-Check).
[pidusage] / /proc/uptime: Docker-typisch, kein Hinweis auf den libuv-Crash.
Zu deinen Fragen:
(1) Als Node/libuv-Absturz ja, nicht als spezieller 7.2.2-Bug. (2) Admin 8.0.14 im Diag konsistent — unwahrscheinlich als direkter Auslöser; halbes Update trotzdem per CLI bereinigen. (3) Docker/Kernel allein erklären die Assertion selten — entscheidend bleibt die FD-/epoll-Situation in Node. (4) Paperless (Docker auf der NAS) steht im Diag als Adapter paperless-ngx 1.0.2; in den Logs keine Fehlerkette bis zur Assertion. (5) Test sinnvoll: aktuelles buanet-Image, Controller aktuell halten; Gegenprobe Node 20 auf Daten-Kopie. (6) Core + gdb oder Adapter-Halbierung — in deinen Logs steht kein klarer Auslöser-Adapter.

Vorschlag: VIS-Projekt(e) mit Invalid group id aus dem laufenden Betrieb nehmen, Skript Alexa_SSML-… absichern, optional Multihost-Slave kurz stoppen zum Test, dann Adapter per Halbierung (viele Verbindungen: Shelly, UPnP, MQTT, …). Neuinstallation nur, wenn es auch minimal noch crasht.

[Happyuser20]

Hallo

ich habe die VIS Fehler mal bereinigt und alle Projektleichen gelöscht. Zudem bin ich von buanet/iobroker:v11.1.0 mit Node.js 24.21.0 auf buanet/iobroker:v11.1.0-build.20260920.013345 mit Node.js 22.23.2 zurückgegangen. Bis jetzt läuft der IOBroker seitdem wieder stabil.
Das latest von Buanet und der Admin Adapter waren die letzten Updates die ich gemacht habe, zuvor lief er bereits 66 Tage ohne Probleme.

Gruß
HappyUser20

[OliverIO]

@Happyuser20

Meine KI sagt, dieser Fehler führt darauf zurück, dass ein file handle/file descriptor durch das Betriebssystem als ungültig angesehen wird, obwohl uvlib es sollte noch gültig sein. Leider fehlen zusätzliche Fehler Informationen.
Um das mehr im Detail analysieren zu können, benötigt man einen core dump, den das Betriebssystem genau an dieser Stelle des Absturzes anfertigen kann.
Dazu musst du prüfen, ob das auf der Synology aktiviert ist.
Ansonsten aktivieren und diesen Core dump der KI zur Analyse übergeben.
Dann kann man herausfinden, um welche Datei es sich konkret handelt.
Prüfe auch mal noch, ob es im Systemlog ein out of Memory Ereignis gab. Nicht, dass das Betriebssystem ein Prozess abgeschossen hat und sich der file handle darauf bezogen hat.
Die hohen CPU Zeiten könnten ein Hinweis auf swapping sein, also zu diesem Zeitpunkt aktuell gerade wenig freier Speicher, was wiederum ein Vorbote von oom ist.