ioBroker doesnt Start / Crashes.... -> startup.sh - Segmentation fault

[dnnrwttr]

Hallo ich betreibe seit geraumer Zeit ioBroker über eine Docker-Umgebung auf meinem Linux Homeserver. Seit geraumer Zeit bekomme ich bei nahezu jedem Start oder spätestens nach ein paar Minuten die ganz unten stehende Meldung "/opt/scripts/iobroker_startup.sh: line 509: 88 Segmentation fault gosu iobroker node node_modules/iobroker.js-controller/controller.js"

Mal nachdem man den ioBroker übers Webinterface aufrufen konnte, mal bevor überhaupt was lief... Was kann ich tun? Diese Probleme hatte ich mit einer nativen Installation nie.

`--------------------------------------------------------------------------------

------------------------- 2022-09-12 08:54:43 -------------------------

---

---

----- Welcome to your ioBroker-container! -----

----- Startupscript is now running. -----

----- Please be patient! -----

---

---

----- Debugging information -----

---

----- System -----

----- arch: x86_64 -----

----- hostname: iobroker -----

---

----- Docker-Image -----

----- image: v6.1.0 -----

----- build: 2022-04-26T23:46:59+00:00 -----

---

----- Versions -----

----- node: v14.19.1 -----

----- npm: 6.14.16 -----

---

----- ENV -----

----- SETGID: 1000 -----

----- SETUID: 1000 -----

---

---

----- Step 1 of 5: Preparing container -----

---

Nothing to do here.

---

----- Step 2 of 5: Detecting ioBroker installation -----

---

Existing installation of ioBroker detected in /opt/iobroker.

---

----- Step 3 of 5: Checking ioBroker installation -----

---

(Re)Setting folder permissions (This might take a while! Please be patient!)...

Done.

Fixing "sudo-bug" by replacing sudo in iobroker with gosu...

Done.

---

----- Step 4 of 5: Applying special settings -----

---

Some adapters have special requirements/ settings which can be activated by the use of environment variables.

For more information see ioBroker Docker Image Docs (https://docs.buanet.de/iobroker-docker-image/docs/).

---

----- Step 5 of 5: ioBroker startup -----

---

Starting ioBroker...

================================== > LOG REDIRECT system.adapter.admin.0 => true [starting]

/opt/scripts/iobroker_startup.sh: line 509: 88 Segmentation fault gosu iobroker node node_modules/iobroker.js-controller/controller.js`

[buanet]

Hallo, ehrlich gesagt habe ich keine Ahnung wie ich dir da helfen kann. "Segmentation fault" ist m. E. ein Speicherfehler. Kommt z.B. wenn eine Applikation auf Speicher zugreift, der von einer anderen Applikation reserviert ist oder wenn mehr Speicher reserviert wird, als tatsächlich vorhanden ist. Ich denke nicht, dass das ein Problem aus dem Docker Container ist, Hast du noch andere Container laufen? Wie sehen da die Logs aus? Arbeitest du auf deinem Homeserver (von dem wir im übrigen nicht wissen was das für ein System ist) zufällig auch mit virtuellen Maschinen oder LXC Containern?

MfG, André

[dnnrwttr]

Moin André,

also das Problem hatte ich nur bei dem ioBroker Container. Habe noch unzählige andere am laufen, ohne Probleme. Ich habe irgendwann aus Spaß einen Reboot vom gesamtem Srv gemacht, danach lief alles wieder..

Ich habe keine VM's oder LXC Container in betrieb sondern nur ein paar Docker Container. Ich denke wir können das Ganze hier erstmal schließen...

Server ist ein alter mini PC (mit ausreichend Power)

[dnnrwttr]

Hi,

sorry ich muss reopenen... Ich hatte jetzt einige male den Srv Rebooten müssen und habe echt massive Probleme den Container stabil zum laufen zu kriegen...

Ich habe reboots probiert, Ebenfalls des öfteren: iobroker stop npm rebuild curl -sL https://iobroker.net/fix.sh | bash - iobroker start

leider nur sehr unzuverlässig / fast nie erfolgreich.

Nun hatte ich die Schnauze wirklich gestrichen voll und wollte einen frischen Docker Container aufziehen (nachfolgende docker compose gebaut)... Und siehe da: Selbes Problem! Komplett nackter Container mit frischem volume hat ebenfalls segmentation - faults... Das Problem habe ich bei meinen 20-24 anderen Containern nicht.

Ich brauche wirklich dringend Hilfe :/

Aktuellste Meldung "alter Container" /opt/scripts/iobroker_startup.sh: line 528: 392 Segmentation fault gosu iobroker node node_modules/iobroker.js-controller/controller.js

Meldung vom "frischen Container": Starting ioBroker...

host.iobroker check instance "system.adapter.admin.0" for host "iobroker" host.iobroker check instance "system.adapter.discovery.0" for host "iobroker" host.iobroker check instance "system.adapter.backitup.0" for host "iobroker" /opt/scripts/iobroker_startup.sh: line 528: 127 Segmentation fault gosu iobroker node node_modules/iobroker.js-controller/controller.js

Unterbau ist mein Mini-PC Intel(R) Pentium(R) CPU G4400T @ 2.90GHz, 16GB Ram und basiert auf einem Debian 11

[dnnrwttr]

Zusatzinfo: Manchmal komme ich noch aufs Web Interface vom ioBroker. Manchmal dauerts 5 Min bis er "abstürzt" manchmal können auch 1-2 Stunden vergehen. In den meisten Fällen ist es aber direkt nach 0.5-5 Min nach start des Containers "spürbar"

[Apollon77]

Und welcher Fehler kommt wenn er abstürzt?

[dnnrwttr]

"/opt/scripts/iobroker_startup.sh: line 528: 127 Segmentation fault gosu iobroker node node_modules/iobroker.js-controller/controller.js"

(untersschiedliche line und zeichen Zahlen, jedoch ausschließlich "....segmentation fault....")

Ich habe auch schonmal im "alten" Container npm deinstalliert und neu installiert. Wenn ich dann z.b. npm install mache dann kommt ebenfallls gerne mal ein segfault. Ich bin am Ende meines Lateins :S

"root@iobroker:/opt/iobroker# npm install npm WARN skipping integrity check for git dependency https://git@github.com/luca-saggese/samsungtv.git Segmentation fault⠂) ⠧ reify:fsevents: timing reifyNode:node_modules/osx-temperature-sensor Completed in 165ms"

[Apollon77]

Ich hab mal gegoogelt ... hier sind verewandte threads:

• https://github.com/ClickHouse/ClickHouse/issues/36293 ... irgendwas mit "tcc als compiler" als grund ... "gosu" scheint irgendwie auf etwas hinzuweisen was mit "su" zu tun hat bzw switch von usern oder so in commands und dabei ein segfault

[dnnrwttr]

@Apollon77 im ioBroker Startscript sieht man auch folgenden Eintrag:

´Step 3 of 5: Checking ioBroker installation
(Re)Setting folder permissions (This might take a while! Please be patient!)... Done. Fixing "sudo-bug" by replacing sudo in iobroker with gosu... Done.´

Das heißt für mich, dass das eigentlich schon Beachtung gefunden haben sollte?! Oder interpretierst du das anders?

[buanet]

Kleiner Hinweis:

iobroker stop npm rebuild curl -sL https://iobroker.net/fix.sh | bash - iobroker start

Das kann nichts werden. Im Container wird nicht mit iobroker stopgestoppt. Wenn du solche Aktionen machst , verwende bitte das maintenance script.

Das heißt für mich, dass das eigentlich schon Beachtung gefunden haben sollte?! Oder interpretierst du das anders?

Vielleicht hat dein System ein Problem mit gosu?? Gosu wird im container statt sudo verwendet...

[Apollon77]

Jetzt ist die Frage wo dieses "gosu" herkommt was da genutzt wird - wenn ich den einen Link richtig lese passiert der Fehler wenn das "falsch" compiled wurde ... @buanet vllt ein pointer in die richtige Richtung?!

[dnnrwttr]

@buanet das mit iobroker stop habe ich auch mit der Weile bemerkt. Ich hatte dann pkill iobroker bzw. io benutzt :S Ging danach zumindest :)

Ich schau mir gern noch das maintenance skript in meiner Konstellation mal an! Aber ich bin dennoch n bissl verwirrt, dass ich den segfault auch mit nem frischen Container bekomme.. Da konnte ich ja nichts großartig rummurksen.

Vielleicht bin ich einfach noch nicht so mega tief in Docker etc. drin aber ich hätte jetzt gedacht, dass das Startskript innerhalb des Containers sudo durch gosu ersetzt und dass das dann unabhängig davon ist wie sich der host dazu verhalten würde?! Oder bin ich total falsch?

[Apollon77]

@soRailicious Andre hat die interessante Frage gestellt ... scheinbar tritt das Issue gerade primär bei Debian 11 als Hostsystem auf ... zumindestens die 2 oder 3 Berichte die ich gehört habe würde das vermuten lassen.

[dnnrwttr]

Ich habe das schon länger mit dem segfault. ABER ich habe locker 6 Monate den Server nicht neugestartet gehabt oder rumgespielt.... Davor hatte ich das nämlich auch schon, als ich frisch auf Debian 11 geswitched bin....

Kann ich irgendwie helfen?! Ich würd das super gern stable am laufen haben... Ist echt unschön wenn der ioBroker nicht geht :D

[dnnrwttr]

Wenn ich den Befehl "gosu iobroker node node_modules/iobroker.js-controller/controller.js" aus der Fehlermeldung in der Bash des Containers ausführe dann "startet" der ioBroker wieder (zumindest manchmal... Das ist echt rein nach Zufall...). <- da hängt er jetzt z.B. gerade (frischer Container)... Beim alten hatte er sich wieder gefangen. Sehr sehr komisch.

Jetzt die große Frage... Alles auf ein ubuntu umziehen und Ruhe?! Oder Chance auf Lösung (in absehbarer Zeit)?!

[buanet]

Also am Debian 11 allein kann es nicht liegen. Bei mir basiert alles darauf (VM, LXC) und ich hatte noch nie dieses Problem.

@soRailicious Ich weiß auch nicht was für eine Lösung in absehbarer Zeit du dir erwartest. Bisher bist du offenbar der Einzige der dieses Problem hat, gleichzeitig aber sicher nicht der einzige der ioBroker unter Docker auf nem Mini PC mit Pentium CPU und Debian 11 laufen hat. Die Frage ist wie ich dir hier helfen kann wenn ich den Fehler nicht reproduzieren kann. Im Moment habe ich einfach keinen Ansatz für eine Lösung...

Hast du mal in der Community gefragt ob es weitere User gibt, die ähnliche Erfahrungen gemacht haben?

Wie ist dein Container konfiguriert? Nutzt du Host Netzwerk oder reichst du USB durch? Andere Schweinereien dabei? Ist deine UID/GID korrekt gemappt? Privilegierter Modus? Das ist für mich leider alles nur stochern im Nebel. Google schmeißt da ja leider auch nicht so viel raus... Sorry.

MfG, André

[dnnrwttr]

Nunja... Ich tu das ja grad ganz bewusst hier, bei dir :) Gerne können wir zusammen troubleshooten?! Bridge (macvlan selbes Verhalten), keine USB Durchreichung, priviligiert, UID / GID = 1000 (sollte passen, ist bei den anderen containern auch so)...

Wäre halt jetzt echt bitter wegen diesem einen Container meine gesamte Farm umziehen zu müssen :/

Und wie gesagt ist halt auch mit frischen containern ohne special config so (siehe oben)...

Hier... Neustart und das von oben probiert.. ergibt das... Wie man sieht hilft da wirklich nichts verlässlich. Habe aber auch keine Lust nach jedem Neustart 5 Stunden den ioBroker zu überwachen ob segmentation fault kommt oder nicht... Wenn er die 5 Stunden durchhält läuft er auch ohne murren! Aber kann ja keine Dauerlösung sein.

Maintenance Script:

Dann warte ich 2-3 Minuten... führe den maintenance upgrade nochmal durch. Diesmal läuft er bis zum Schluss aber dann kommt wieder segmentation fault :/

:(

[dnnrwttr]

Jetzt wirds echt gemein...

Ich habe meinen kompletten, verdammten Server auf Ubuntu migriert und ratet mal was passiert ist.......... Ich könne weinen!

Kann mir wirklich keiner helfen?!

[buanet]

Also am Debian 11 allein kann es nicht liegen. Bei mir basiert alles darauf (VM, LXC) und ich hatte noch nie dieses Problem.

Hast du mal in der Community gefragt ob es weitere User gibt, die ähnliche Erfahrungen gemacht haben?

Sorry, aber das war Kern meines letzten Statements.

Ich wüsste ehrlich gesagt nicht wie ich dir aktuell helfen könnte. Natürlich kann ich mal nen Blick drauf werfen oder Google befragen aber dann hört es auch schon auf. Ich bin regelmäßig im Discord Voice Chat, Vielleicht lässt es sich auf der Tonspur besser austauschen? Dann kannst du es vielleicht auch mal zeigen?

Hast du mal die Logs auf dem Host gecheckt? Wenn der Fehler im Container auftritt, gibt es da vielleicht ne Meldung?

[dnnrwttr]

Ja das stimmt, aber nicht der Kern von Apollons Statement. UND bei meinen ersten Versuchen auf Ubuntu (sowohl als VM als auch auf einer zweiten SSD lief der ioBroker mit meinem Backup und auch frisch!)

Nun habe ich aktuell die Vermutung, dass der RAM ggf. einen weg haben könnte?! Wobei ich dann nicht verstehe wieso alle anderen Container ohne Murren laufen (von kleinen wie motioneye, bis hin zu größeren wie paperless, laufen sie).

Ich würde vorschlagen ich teste die Tage/morgen nochmal mit anderem RAM, sollte ich nicht weiterkommen lass uns gerne mal im Discord sprechen, dann machen wir mal zusammen eine kleine Session, dann kannst du ggf auch gezielter schauen - macht doch Sinn oder?

Ich möchte ungern jetzt vom ioBroker weg :(

[dnnrwttr]

Moin, noch keinen anderen Ram probiert. Aber habe mal die Slots getauscht. Ich dachte jetzt wäre wieder Ruhe...

2022-10-07T12:58:36.637323967Z /bin/sh: 1: iw: not found 2022-10-07T12:58:36.637348720Z 2022-10-07T12:58:36.641679930Z /bin/sh: 1: iw: not found 2022-10-07T12:58:36.641702065Z 2022-10-07T12:58:36.660467579Z /bin/sh: 1: hcitool: not found 2022-10-07T12:58:36.660489232Z 2022-10-07T13:49:52.615684324Z /opt/scripts/iobroker_startup.sh: line 528: 401 Segmentation fault (core dumped) gosu iobroker node node_modules/iobroker.js-controller/controller.js

Diesmal hat er sich fast eine Stunde zeit gelassen bis ausgestiegen wurde. In welche Logs soll ich ggf. mal schauen @buanet? Kannst Du mir da die Pfade nennen?

Auszug aus: kern.log in /var/logs/

Oct 7 13:32:07 WR11 kernel: [ 190.072765] device veth8810320 left promiscuous mode Oct 7 13:32:07 WR11 kernel: [ 190.072772] br-107ef9e04fec: port 1(veth8810320) entered disabled state Oct 7 13:33:20 WR11 kernel: [ 262.850931] apport-checkrep[9651]: segfault at 7f8825227ac0 ip 0000559561eb51df sp 00007ffff202c260 error 6 in python3.10[559561dd7000+2b4000] Oct 7 13:33:20 WR11 kernel: [ 262.850942] Code: 00 48 83 f8 ff 0f 84 98 02 00 00 48 8b b4 24 e0 00 00 00 48 85 f6 0f 84 87 02 00 00 4d 85 c0 0f 85 e3 1f 00 00 41 0f b7 7d 00 <48> 83 06 01 49 8d 57 08 4d 89 e9 49 89 37 44 8b 9c 24 40 01 00 00 Oct 7 13:34:08 WR11 kernel: [ 311.136574] package-data-do[9806]: segfault at 7fc25677cff8 ip 00005559ddb39230 sp 00007ffd08e5c730 error 4 in python3.10[5559dda79000+2b4000] Oct 7 13:34:08 WR11 kernel: [ 311.136586] Code: 00 e9 e4 fe ff ff 0f 1f 40 00 41 56 41 55 49 89 fd 41 54 55 48 89 f5 53 48 8b 1f 48 89 da 48 39 df 74 54 0f 1f 80 00 00 00 00 <48> 8b 42 08 48 8b 4a 10 83 e0 01 48 c1 e1 02 48 09 c8 48 83 c8 02 Oct 7 13:35:25 WR11 kernel: [ 387.845084] php-fpm7[5603]: segfault at 7f80f0dd4e7d ip 00007f88f21d185a sp 00007fffb1ca14d8 error 4 in ld-musl-x86_64.so.1[7f88f21c3000+48000] Oct 7 13:35:25 WR11 kernel: [ 387.845095] Code: 74 16 48 89 46 08 48 8b 00 48 89 06 48 89 70 08 48 8b 46 08 48 89 30 c3 48 89 76 08 48 89 36 48 89 37 c3 40 f6 c7 0f 74 01 f4 <44> 8a 47 fd 0f b7 57 fe 44 89 c1 41 83 e0 1f 83 e1 1f 80 7f fc 00 Oct 7 14:24:41 WR11 kernel: [ 3343.735874] curl[17826]: segfault at 7f005cbfd8ad ip 00007f405d3adde6 sp 00007fff5b290fc8 error 4 in libc-2.31.so[7f405d335000+15a000] Oct 7 14:24:41 WR11 kernel: [ 3343.735885] Code: 0f 1f 40 00 66 0f ef c0 66 0f ef c9 66 0f ef d2 66 0f ef db 48 89 f8 48 89 f9 48 81 e1 ff 0f 00 00 48 81 f9 cf 0f 00 00 77 6a 0f 6f 20 66 0f 74 e0 66 0f d7 d4 85 d2 74 04 0f bc c2 c3 48 83 Oct 7 14:31:12 WR11 kernel: [ 3735.500675] curl[19001]: segfault at 7f664501c9a0 ip 00007f664501c9a0 sp 00007fff4485e938 error 14 Oct 7 14:31:12 WR11 kernel: [ 3735.500684] Code: Unable to access opcode bytes at RIP 0x7f664501c976. Oct 7 14:31:12 WR11 kernel: [ 3735.566263] apport[19011]: segfault at 7fab0b9e4858 ip 0000564505ada230 sp 00007fffbf377fa0 error 4 in python3.10[564505a1a000+2b4000] Oct 7 14:31:12 WR11 kernel: [ 3735.566273] Code: 00 e9 e4 fe ff ff 0f 1f 40 00 41 56 41 55 49 89 fd 41 54 55 48 89 f5 53 48 8b 1f 48 89 da 48 39 df 74 54 0f 1f 80 00 00 00 00 <48> 8b 42 08 48 8b 4a 10 83 e0 01 48 c1 e1 02 48 09 c8 48 83 c8 02 Oct 7 14:31:12 WR11 kernel: [ 3735.566288] Process 19011(apport) has RLIMIT_CORE set to 1 Oct 7 14:31:12 WR11 kernel: [ 3735.566290] Aborting core Oct 7 14:31:17 WR11 kernel: [ 3739.819704] postgres[19018]: segfault at 4000000000 ip 00007f9ce4890c65 sp 00007ffee8197b98 error 4 in libc-2.31.so[7f9ce4777000+15a000] Oct 7 14:31:17 WR11 kernel: [ 3739.819715] Code: 3b 06 00 77 20 4d 63 0c 93 48 01 d6 48 01 d7 4d 01 d9 41 ff e1 0f 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 40 38 fe 7e 5b 0f 6f 06 48 89 f9 48 83 e7 f0 48 83 c7 10 49 89 c8 48 29 f9 48

Und Zusatz: Wenn sich der Segfault Fehler einmal "eingeschlichen hat" dann sind die nachfolgenden Starts bis mindestens einem Reboot der gesamten Maschine immer recht schnell am punkt "seg fault" angelangt. Habe jetzt z.b. 2x den Container schon neugestartet => immer wieder seg fault nach wenigen Sekunden, nach dem Start

[dnnrwttr]

Hitzeproblem kann ich auch ausschließen. Habe gerade mal den Server für über 60 Minuten ausgelassen, exakt selbes Ergebnis.

Aus Spaß jetzt mal node deinstalliert im Container und von der 16.17 auf 18.00 hochgezogen.. Danach startet der Container sofort .. Mal sehen wie lang es hält und ob überhaupt. Ich halte euch auf dem laufenden.

[dnnrwttr]

Edit: Wieder Segmentation Fault... Ich glaube das kriegen wir dann wohl echt nicht mehr gelöst.

[Apollon77]

Was ist denn der untershcied vom alten zum neuen container? Mal das relevante binary verglochen? mal versucht das binary auszutauschen?

[dnnrwttr]

Was ist denn der untershcied vom alten zum neuen container? Mal das relevante binary verglochen? mal versucht das binary auszutauschen?

Ich habe einfach mal mit meinem typischen Volume wo ich alle meine ioBroker Skripte, Adapter, etc. drin hab getestet ABER auch halt eine komplett leere ioBroker Installation mit einem frischen volume... Ich bin wirklich am Ende meines Lateins.. Mir fehlt leider auch das Wissen um vernünftig debuggen zu können. Scheinbar bin ich aber wohl Weltweit der einzige mit diesem Problem...

Dann wird wohl die Lösung sein, entweder den Server zu entsorgen oder vom ioBroker wegzugehen. Kommen ja leider nicht weiter. Ich weiß nicht wiev iele Stunden ich da noch investieren soll. Ohne Hilfe werde ich das nicht mehr lösen können, leider...

Mal ein weiterer Snipped wenn ich den _gosu iobroker node nodemodules/iobroker.js-controller/controller.js Befehl manuell ausführe (dort scheint der segfault ja immer aufzutauchen).

`root@iobroker:/opt/iobroker# gosu iobroker node node_modules/iobroker.js-controller/controller.js ================================== > LOG REDIRECT system.adapter.admin.0 => true [starting] host.iobroker check instance "system.adapter.admin.0" for host "iobroker" host.iobroker check instance "system.adapter.javascript.0" for host "iobroker" host.iobroker check instance "system.adapter.sql.0" for host "iobroker" host.iobroker check instance "system.adapter.telegram.0" for host "iobroker" host.iobroker check instance "system.adapter.whatsapp-cmb.0" for host "iobroker" host.iobroker check instance "system.adapter.influxdb.0" for host "iobroker" host.iobroker check instance "system.adapter.alexa2.0" for host "iobroker" host.iobroker check instance "system.adapter.fritzbox.0" for host "iobroker" host.iobroker check instance "system.adapter.hue.0" for host "iobroker" host.iobroker check instance "system.adapter.mihome-vacuum.0" for host "iobroker" host.iobroker check instance "system.adapter.ping.1" for host "iobroker" host.iobroker check instance "system.adapter.samsung.1" for host "iobroker" host.iobroker check instance "system.adapter.sonoff.0" for host "iobroker" host.iobroker check instance "system.adapter.sony-bravia.0" for host "iobroker" host.iobroker check instance "system.adapter.tr-064.0" for host "iobroker" host.iobroker check instance "system.adapter.unifi.0" for host "iobroker" host.iobroker check instance "system.adapter.accuweather.0" for host "iobroker" host.iobroker check instance "system.adapter.adguard.0" for host "iobroker" host.iobroker check instance "system.adapter.backitup.0" for host "iobroker" host.iobroker check instance "system.adapter.calendar.0" for host "iobroker" host.iobroker check instance "system.adapter.cec2.0" for host "iobroker" host.iobroker check instance "system.adapter.cloud.0" for host "iobroker" host.iobroker check instance "system.adapter.discovery.0" for host "iobroker" host.iobroker check instance "system.adapter.easee.0" for host "iobroker" host.iobroker check instance "system.adapter.hs100.0" for host "iobroker" host.iobroker check instance "system.adapter.info.0" for host "iobroker" host.iobroker check instance "system.adapter.nuki.0" for host "iobroker" host.iobroker check instance "system.adapter.onvif.0" for host "iobroker" host.iobroker check instance "system.adapter.pushbullet.0" for host "iobroker" host.iobroker check instance "system.adapter.socketio.1" for host "iobroker" host.iobroker check instance "system.adapter.tankerkoenig.0" for host "iobroker" host.iobroker check instance "system.adapter.text2command.0" for host "iobroker" host.iobroker check instance "system.adapter.vis.0" for host "iobroker" host.iobroker check instance "system.adapter.vw-connect.0" for host "iobroker" host.iobroker check instance "system.adapter.web.0" for host "iobroker" host.iobroker check instance "system.adapter.wled.0" for host "iobroker" /opt/iobroker/node_modules/@iobroker/adapter-core/build/utils.js:83 throw new Error("Cannot resolve adapter class"); ^

Error: Cannot resolve adapter class at resolveAdapterConstructor (/opt/iobroker/node_modules/@iobroker/adapter-core/build/utils.js:83:11) at Object. (/opt/iobroker/node_modules/@iobroker/adapter-core/build/utils.js:92:19) at Module._compile (node:internal/modules/cjs/loader:1126:14) at Object.Module._extensions..js (node:internal/modules/cjs/loader:1180:10) at Module.load (node:internal/modules/cjs/loader:1004:32) at Function.Module._load (node:internal/modules/cjs/loader:839:12) at Module.require (node:internal/modules/cjs/loader:1028:19) at require (node:internal/modules/cjs/helpers:102:18) at Object. (/opt/iobroker/node_modules/@iobroker/adapter-core/build/controllerTools.js:6:15) at Module._compile (node:internal/modules/cjs/loader:1126:14)

================================== > LOG REDIRECT system.adapter.admin.0 => false [Process stopped] ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] ================================== > LOG REDIRECT system.adapter.javascript.0 => false [Process stopped] ================================== > LOG REDIRECT system.adapter.javascript.0 => false [system.adapter.javascript.0.logging] ================================== > LOG REDIRECT system.adapter.admin.0 => false [Process stopped] ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] ================================== > LOG REDIRECT system.adapter.javascript.0 => false [Process stopped] ================================== > LOG REDIRECT system.adapter.javascript.0 => false [system.adapter.javascript.0.logging] /opt/iobroker/node_modules/@iobroker/adapter-core/build/utils.js:83 throw new Error("Cannot resolve adapter class"); ^

Error: Cannot resolve adapter class at resolveAdapterConstructor (/opt/iobroker/node_modules/@iobroker/adapter-core/build/utils.js:83:11) at Object. (/opt/iobroker/node_modules/@iobroker/adapter-core/build/utils.js:92:19) at Module._compile (node:internal/modules/cjs/loader:1126:14) at Object.Module._extensions..js (node:internal/modules/cjs/loader:1180:10) at Module.load (node:internal/modules/cjs/loader:1004:32) at Function.Module._load (node:internal/modules/cjs/loader:839:12) at Module.require (node:internal/modules/cjs/loader:1028:19) at require (node:internal/modules/cjs/helpers:102:18) at Object. (/opt/iobroker/node_modules/@iobroker/adapter-core/build/controllerTools.js:6:15) at Module._compile (node:internal/modules/cjs/loader:1126:14)

Segmentation fault (core dumped)`

[buanet]

Kannst Du mir da die Pfade nennen?

https://wiki.ubuntuusers.de/Logdateien/

Ich würde als erstes mal dmesg auf dem Host probieren. Einfach mal den Befehl auf dem Host ausführen nachdem der Container den Fehler meldet. Vielleicht haben wir da ja direkt ne Info was schief geht...

MfG, André

[buanet]

Gibt es Neuigkeiten von der Segmentation Fault front? Können wir den issue schließen?

MfG, André

[dnnrwttr]

Hi Andre,

mach sonst zu... Ich habe den privilegierten Modus bei Container Start nochmal eingestellt und vm.overcommit_memory auf 1 gesetzt... Ich bilde mir ein, dass seitdem Ruhe herrscht.. Hatte auch schon 1-2 Neustarts zwischen drin und lief ohne Probleme.