Wartung am 15.11. – Forum ab 22:00 Uhr nicht erreichbar

[smartboart]

@Homoran die Teile werden ueber meine DC ups 12v gespeist.. Jeder Verbraucher hat sein eigenen 12v auf 5V converter welche jeweils 3A koennen... Natürlich extra abgesichert. Das ist leider nicht das Thema...

[Homoran]

@smartboart
Wenn es nicht die Stromversorgung (Kabel micro USB Stecker) oder die SOC Temperatur ist, tippe ich wirklich auf die Überlastung des RasPi mit Aufgaben.

Es ist, auch wenn es manchmal so dargestellt wird, eben kein vollwertiger PC.

[smartboart]

@Homoran ja ich befürchte es fast... Die soc temp pendelt sich auf 57 Grad ein... Ohne fremdbelüftung.. Vlt sollte ich das noch probieren beim tinker habe eine zusätzliche Belüftung. Welche temp ist denn vertretbar... Hab leider keinen Vergleich... Ausser snips aber der ist noch wärmer...

[Homoran]

@smartboart
60° ist schon eine Hausnummer.

Irgendwo ist Temperatur max im Betriebssystem hinterlegt.
Hast du wenigstens einen Kühlkörper drauf?

[AlCalzone]

@smartboart sagte in ioBroker (JS Controller) stürzt alle 6-8 Tage ab:

2019-04-06 20:43:15.437 - error: TypeError: First argument must be a string, Buffer, ArrayBuffer, Array, or array-like object.
at Function.Buffer.from (buffer.js:183:11)
at Buffer (buffer.js:158:17)
at clone (/opt/iobroker/node_modules/iobroker.js-controller/lib/objects/objectsInMemServer.js:1936:24)
at clone (/opt/iobroker/node_modules/iobroker.js-controller/lib/objects/objectsInMemServer.js:1940:29)
at clone (/opt/iobroker/node_modules/iobroker.js-controller/lib/objects/objectsInMemServer.js:1940:29)
at clone (/opt/iobroker/node_modules/iobroker.js-controller/lib/objects/objectsInMemServer.js:1940:29)
at _getObjectList (/opt/iobroker/node_modules/iobroker.js-controller/lib/objects/objectsInMemServer.js:2863:39)
at checkObjectRights (/opt/iobroker/node_modules/iobroker.js-controller/lib/objects/objectsInMemServer.js:2912:28)
at checkObjectRights (/opt/iobroker/node_modules/iobroker.js-controller/lib/objects/objectsInMemServer.js:1869:20)
at ObjectsInMemServer.getObjectList (/opt/iobroker/node_modules/iobroker.js-controller/lib/objects/objectsInMemServer.js:2908:13)

Auch wenn der Raspi am Limit läuft, das sieht mir schwer nach einem Bug aus. Lässt sich irgendwie eingrenzen, was der Auslöser ist?

[smartboart]

@Homoran ja habe wo es geht habe ich einen Kühlkörper sitzen, glaube 3 stück...Ist halt im geschlossenen Verteilerkasten mit Hutschienengehäuse auch geschlossen. Der Tinker war jenseits von gut und böse und hat deshalb habe ich dem nen Lüfter spendiert bekommen. Geht natürlich beim Raspi auch....

[smartboart]

@AlCalzone nicht wirklich habe schon mehrere Sachen probiert...Auf USB Betrieb umgestellt ohne SD, wo es ging Adapter auf den Master geschoben, und von redis auf file system umgestellt. Letzteres brachte eine Verbesserung, läuft bis jetzt stabil. Auch die Skripte reagieren bis jetzt noch wieder ohne aussetzer.

[RoE19xx]

Kurzes Zwischenfeedback:

Seit dem 03.04.2019 ist es zu keinem Absturz mehr gekommen.
Ich habe wie angekündigt den BackitUp Adapter (Verison 1.1.3) mal testweise deaktiviert.

Das beweißt zwar noch nicht das diese die Ursache ist/war aber es ist schon mal ein Fortschritt.
Ich werde das jetzt noch eine Zeit lang mit deaktiviertem Adapter beobachten.

Wenn es keine Probleme mehr gibt, werde ich für das Standardbackup eine andere, markante Zeit einstellen und den Adapter wieder aktivieren. Dann sollte sich zeigen ob der Adapter die Ursache bzw. ein Mitverursacher ist.

[Homoran]

@RoE19xx
Der Adapter wird sicher nicht der Verursacher sein.

Allerdings braucht er z.B. zum komprimieren der Daten wahrscheinlich etwas mehr RAM als du noch hast.

[RoE19xx]

@Homoran
"Gewagte Aussage"
Warum wird der Adapter "sicher" nicht der Verursacher sein?
Das war ja auch keine Kritik an dem Adapter oder ähnliches. Ich versuche ja nur das Problem einzugrenzen.
Wenn das gelingt, kann man ein Problem per Github melden. Der Entwickler ist für entsprechende Informationen sicher dankbar.

Das mit dem Ram würde ich nicht gleich in Betracht ziehen. Ich weiß zwar nicht wie es zum Zeitpunkt vom Absturz ausgeschaut hat. Aber die (betroffene) ioBroker Hauptinstanz läuft auf einer VM in einem NUC und hat 4 GB RAM zur Verfügung (davon aktuell laut ioBroker noch 1,3 GB frei).

Nach Deiner Theorie müßte der Adapter (beim komprimieren der Daten) die meistens ioBroker RPi's mit 1 GB Gesamtspeicher an ihre Grenzen bringen.

[Homoran]

@RoE19xx sagte in ioBroker (JS Controller) stürzt alle 6-8 Tage ab:

Warum wird der Adapter "sicher" nicht der Verursacher sein?

Weil der Adapter bei hunderten usern ohne Probleme läuft.
Lediglich bei usern, bei denen das RAM zu knapp ist, kommt es zu Speicherproblemen.

Also ist in fiesen Fällen nicht der Adapter, sondern das mangelnde RAM der Verursacher.

@RoE19xx sagte in ioBroker (JS Controller) stürzt alle 6-8 Tage ab:

Ich weiß zwar nicht wie es zum Zeitpunkt vom Absturz ausgeschaut hat.

Das wäre aber bei deiner Argumentationskette schon wichtig.

@RoE19xx sagte in ioBroker (JS Controller) stürzt alle 6-8 Tage ab:

auf einer VM in einem NUC und hat 4 GB RAM zur Verfügung (davon aktuell laut ioBroker noch 1,3 GB frei).

Auch in solchen Fällen kam es kurzfristig zu Speicherproblemen.

@RoE19xx sagte in ioBroker (JS Controller) stürzt alle 6-8 Tage ab:

Nach Deiner Theorie müßte der Adapter (beim komprimieren der Daten) die meistens ioBroker RPi's mit 1 GB Gesamtspeicher an ihre Grenzen bringen.

Nur wenn das backup extrem umfangreich ist.
So war es bei einem user eindeutig immer ein total backup, während das minimal brav durchlief

[RoE19xx]

Es ging mir hier nie eine Schuldfrage, sondern immer nur um die Ursache meiner Systemabstürze.

Ich ziehe meinen Hut davor, wieviel von so vielen zu diesem Projekt beigetragen wird. Und es wird würde mir nicht in den Sinn kommen mit dem Finger auf irgendjemand oder irgendetwas zu zeigen nur weil es bei meiner Installation zu Problemen kommt.
Das war auch nie die Absicht, falls das irgendwie so rübergekommen ist.

Ich bin schwer begeistert vom ioBroker und das schon ziemlich lange. Mein System ist mittlerweile doch schon etwas gewachsen und lief bis zum ersten erwähnten Absturz absolut stabil.

Nachdem es dann einige Änderungen am System gab (die genannten Updates), aber auch von Zeit zu Zeit neue Adapter getestet dazugekommen sind, gibt es viele mögliche Ursachen.

Und mit „Ursache“ meine ich lediglich, „welche Änderung hat dazu geführt, das es nun zu Systemabstürzen kommt“.

Ob das nun ein neu verwendeter Adapter ist, oder Updates oder auch eine Kombination aus alledem ist im Grunde erst mal egal. Ich möchte nur herausfinden, so dass ich Maßnahmen setzen kann um mein System wieder in einen stabilen Zustand zu bringen.

Da ich bei der Analyse irgendwann angestanden bin, ging es eben mit Try & Error und dem Ausschließungsprinzip weiter. Nach dem Denkanstoß von @darkiop habe ich dann einfach mal auf gut Glück den BackitUp Adapter wieder deaktiviert.

Und wenn mein System nach dem deaktivieren von einem (in meiner Installation) neuen Adapter wieder stabil laufen sollte und nach erneutem Aktivieren wieder Abstürze auftreten, dann Freue ich mich im ersten Moment einfach nur die Ursache gefunden zu haben.

Wenn es mit dem Adapter am Ende gar nichts zu tun hat, dann geht die Suche eben weiter.

Da ich aber dazu beitragen möchte das Problem genauer zu analysieren, lasse ich nun im ersten Schritt vorerst den Adapter noch eine gewisse Zeit deaktiviert.
Wenn es dabei nicht zu Abstürzen kommt, werde ich eine andere (markante) Backup Zeit als 02:00 einstellen und schauen ob die Abstürze wieder auftreten.
Wenn ja dann finde ich hier ja ggf. Unterstützung wie ich mein System monitoren (Speicherauslastung aufzeichnen) kann um herauszufinden ob wirklich ein Speicherengpass den Absturz hervorruft.

Das würde den Entwickler vermutlich auch interessieren, da zwangsläuft mit wachsenden Installationen (wird bei den meisten begeisterten Anwendern der Fall sein) auch mit zunehmenden Ausfällen zu rechnen wäre. Und ein Backup Adapter findet sicher bei sehr vielen Anwendern Anklang.

Soweit erst mal mein Plan wie ich weiter vorgehen möchte.

Beim BackitUp Adapter hatte ich bisher nur das Standardbackup im Einsatz. Das Komplettbackup oder auch andere Möglichkeiten habe ich noch gar nicht genutzt bzw. aktiviert.

[darkiop]

Nabend Habe leider zur Zeit wenig freie Zeit für die Analyse - aber: Ich habe seit ein paar Tagen das Komplett Backup deaktviert und beobachte auch seit längerem keinen Absturz mehr. ioBroker läuft bei mir im Docker-Container. Die Aussage von @Homoran könnte hier also passen. Ich stelle das bei Gelegenheit aber nochmal nach.

[darkiop]

Wie es Murphy will, ist heute Nacht der Kollege ioBroker abgestürzt Ich habe gestern Abend die Anzahl der Backups für die CCU im Backitup Adapter erhöht (von 7 auf 14, analog meinen Minimal Backups) ... um 5 Uhr ist der ioBroker Prozess dann abgestürzt (das sehe ich gut an meinen dauerhaft aufgezeichneten Werten wie z.B. dem Stromverbrauch) - um 5 Uhr läuft auch das Minimal Backup.

[smartboart]

Will noch kurz meine Lösung posten...Also bei mir war das von mir oben beschrieben Verhalten dem Speichernotstand geschuldet. Hatte also nur indirekt mit redis zu tun...Auch wenn die Probleme mit file system nicht mehr auftraten Die Ursache dafür war das der Chromium Browser bei jedem Bildwechsel immer mehr Speicher vereinnahmt. Da ich meine Vis über view in widget mittel einem State umschalte damit ich nur eine Basisview habe, welche immer gleich ist und die restlichen views im widget angezeigt werden ( muss bei viewwechsel nicht immer alles neu geladen werden) macht die Bedienung flotter...Das hat aber zufolge das alle Anzeigegeräte immer gleich sind also mit umschalten. Mein Schaltschrank Einbau hat nun ein eigens Projekt erhalten und schaltet somit nicht mehr mit um...Somit bleibt der verfügbare Speicher nun bei 500MB. Danke für die Unterstützung...

[darkiop]

Heute bei mir wieder, 5:00 Uhr - der Zeitpunkt des Minimal Backups. Dieses wurde dann auch nicht erstellt. Hab dann die Reste vom iobroker mittels kill -9 beendet und dabei über ps -ef festgestellt das der js-controller backup Prozess auch noch aktiv war. Dem Container stehen theretisch 12GB RAM zur Verfügung, kann mir eigentlich nicht vorstellen das hier etwas knapp wird - zumal die Backups ja auch einige Tage gut laufen und es bei einem manuellen Aufruf bisher auch nie Probleme gab.

[darkiop]

Der Kollege ioBroker hat heute wieder das zeitliche gesegnet .... ich helfe mir jetzt mit einem kleinen Bash Skript das den Docker Container neu startet (läuft alle 15min):

#!/bin/bash
if [[ $(sudo docker exec -it iobroker-odin sh -c "iobroker status") = *not* ]]; then
  echo "$(date '+%Y-%m-%d %H:%M:%S') ioBroker Prozess im Container ist nicht aktiv,  Container wird neu gestartet." 2>&1 | tee /volume1/docker/check-iobroker.log
  sudo docker restart iobroker-odin 2>&1 >/dev/null
else
  echo "$(date '+%Y-%m-%d %H:%M:%S') ioBroker Prozess im Container ist aktiv." 2>&1 | tee /volume1/docker/check-iobroker.log
fi

[simatec]

Was mir hier in der ganzen Diskussion aufgefallen ist, dass hier diskutiert wird, ob backitup an dem Absturz schuld ist, aber kein einziger Log im debug Modus von backitup mal gepostet wird.
Backitup kann vom Aufbau der Backup-Ausführung nicht der Verursacher sein.

Eventuell müssten bei euch mal die Rechte kontrolliert werden.
Dafür gibt es einen Fix für den iobroker Installer (siehe Signatur).

Beim Minimal Backup wird der gleiche Prozess aufgerufen, wie beim manuellen Backup über Konsole mit "iobroker backup".

Wenn ihr bei einem Total Backup iobroker stoppt, werden ebenfalls die gleichen Befehle aufgerufen wie beim manuellen starten und stoppen von iobroker.
Wenn euren iobroker User die Rechte fehlen, kann auch dies dazu führen, dass iobroker nicht mehr gestartet wird.

Auch besteht die Möglichkeit, des fehlenden RAM.
Bei einem Total Backup wird der komplette iobroker Ordner gepackt, was je nach Installationsgröße schon etwas RAM benötigt.
Um hier aber weiter Spekulationen auszuschließen, wäre es wichtig die Instanz von backitup mal auf debug zu stellen und dann im Log zu schauen, was passiert.

[darkiop]

Hallo @simatec,

hatte in der Vergangenheit keine Logs gefunden die auf den Absturz hinwiesen. Habe jetzt aber backitup sowohl in den Optionen selbst als auch die Instanz in den Debug Modus gesetzt. Beim nächsten mal wird dann nochmal geschaut.

Bin allerdings sehr sicher das backitup der Auslöser ist (was ja nicht bedeuten muss das backitup 'Schuld' ist :)), denn

• Die Uhrzeit des Absturzes stimmt immer mit der Uhrzeit des Backups (bei mir nur das Standard + CCU Backup) überein
• Kontrolliert man nach dem Absturz mittels ps -ef die Prozesse sieht man das der js-controller Prozess mit dem Backup Aufruf noch läuft (aber nichts macht, denn die Kontrolle kann durchaus auch mal einige Stunden nach dem Absturz gewesen sein).
• Im folgenden Screen sieht man das es beim minimal Backup (bei mir) passieren muss (immer alle 4-6 Tage ...):

Bei manuellen Backups direkt auf der Shell bzw. aus dem ioBroker WebUI heraus ist mir das Verhalten noch nicht aufgefallen. Werde das aber ggf. heut einfach einige viele male von Hand starten und beobachten.

ioBroker läuft bei mir im Docker Container unter root - also noch ohne Installfix ... der letzte vor ein paar Wochen ging schief, hatte noch keine Zeit das nochmal anzugehen. Therotisch stehen dem Container 12GB RAM zur Verfügung, das sollte also gut ausreichen.

Grüße Thorsten

[darkiop]

Ok - Update: Habe einige Backups auf der Shell laufen lassen und dabei geht auch der js-controller irgendwann auf die Bretter: