NEWS
[gelöst] iobroker nach Neustart "tot"
-
@apollon77 sagte in iobroker nach Neustart "tot":
13 Adapter plus controller ..
aber die sind doch auf den 3 Hosts verteilt!
@amg_666
oder?@homoran Oh OH, ich hatte gesagt, dass es "locker" 13 Instanzen sind, hatte mir das irgendwann mal dokumentiert. Stimmt es sind 13 auf dem MASTER) plus nochmal 10 auf einem Slave, beim 2. Slave weiß ich es nicht mehr genau, auf dem läuft vis inkl diverser vis-ergänzungen
-
Also ich würde sagen: Wiederherstellen aus objects Backup und state backups und wenn es wieder läuft gleich mal mit "top" schauen was der RAM usage sagt
Ich denke 13 Instanzen sind für den RAM zuviel@apollon77 @amg_666
Da geht halt regelmäßig das RAM aus.
Da hilft nur mehr Hubraum. -
@apollon77 @amg_666
Da geht halt regelmäßig das RAM aus.
Da hilft nur mehr Hubraum.@thomas-braun @apollon77
Wie gehe ich denn jetzt weiter vor (unix dummy). "Wiederherstellen aus objects Backup und state backups "
Was genau muss ich da machen? Wenn ich das wieder zum rennen kriege, dann kann ich ja erstmal die Adapter auf ein "basic set" einkürzen und alles was nicht sooo wichtig ist stoppen.
Mehr Hubraum ist eine gute Idee aber den müsste ich mir erstmal besorgen... -
@thomas-braun @apollon77
Wie gehe ich denn jetzt weiter vor (unix dummy). "Wiederherstellen aus objects Backup und state backups "
Was genau muss ich da machen? Wenn ich das wieder zum rennen kriege, dann kann ich ja erstmal die Adapter auf ein "basic set" einkürzen und alles was nicht sooo wichtig ist stoppen.
Mehr Hubraum ist eine gute Idee aber den müsste ich mir erstmal besorgen...@amg_666
Man kopiert eine funktionierende Datei zurück an den Platz wo die kaputte liegt. Wie das geht steht im Mini-HowTo drin.https://forum.iobroker.net/topic/43325/mini-howto-cannot-find-view-system-for-search-host
-
Ok, nochmal beide Logfiles zusammen gecheckt im "Problembereich":
-
15:40:12 wurde controller gekillt von OOM
-
15:40:32 restarted
-
15:46:xx 3 mal fehler das die bak nicht kopiert werden kein weil die .json nicht da ist. das kapiere ich nicht
-
15:48:37 nächster kill
-
15:48:54 restart (übrigens restart counter = 11 ...)
-
15:49:00 beim start: states.json broken, backup genutzt
-
15:50:47 objects.json bak kann nicht geschrieben werden weil .json nicht da ist (kapiere ich nicht)
-
15:52:01 nochmal gleiche meldung
-
15:52:15 Login und Reboot
-
15:53:32 Start nach Reboot, hat geklappt trotz defekter objects.json weil backup genommen
... alles kommt hoch -
15:58:49 neuer oom kill
und dann gibts oom kill loop
Aber schon heute nach um 2 Uhr gabs einen Fall wo die objects.json korrupt war. Es hat aber geklappt aus dem letzten backup zu lesen
also an sich alles ok aber ramist zu heftig
Schau das du drauf kommst, stoppe iobroker, disbale ein paar instanzen manuell per "iobroker stop ...." und schau das es dann wieder läuft. Und schau was den RAM frisst mit "top"
-
-
@amg_666
Man kopiert eine funktionierende Datei zurück an den Platz wo die kaputte liegt. Wie das geht steht im Mini-HowTo drin.https://forum.iobroker.net/topic/43325/mini-howto-cannot-find-view-system-for-search-host
@thomas-braun Daran liegts diesmal noch nicht mal weil er als Fallback scheinbar immer die ".bak" nehmen kann ... die scheint zu tun.
EDIT: DOCH !!!
Der Crash 2021-03-19 16:31:52.066 hat dann alles zerstört. Also dfoch backup File restoren
-
Ok, nochmal beide Logfiles zusammen gecheckt im "Problembereich":
-
15:40:12 wurde controller gekillt von OOM
-
15:40:32 restarted
-
15:46:xx 3 mal fehler das die bak nicht kopiert werden kein weil die .json nicht da ist. das kapiere ich nicht
-
15:48:37 nächster kill
-
15:48:54 restart (übrigens restart counter = 11 ...)
-
15:49:00 beim start: states.json broken, backup genutzt
-
15:50:47 objects.json bak kann nicht geschrieben werden weil .json nicht da ist (kapiere ich nicht)
-
15:52:01 nochmal gleiche meldung
-
15:52:15 Login und Reboot
-
15:53:32 Start nach Reboot, hat geklappt trotz defekter objects.json weil backup genommen
... alles kommt hoch -
15:58:49 neuer oom kill
und dann gibts oom kill loop
Aber schon heute nach um 2 Uhr gabs einen Fall wo die objects.json korrupt war. Es hat aber geklappt aus dem letzten backup zu lesen
also an sich alles ok aber ramist zu heftig
Schau das du drauf kommst, stoppe iobroker, disbale ein paar instanzen manuell per "iobroker stop ...." und schau das es dann wieder läuft. Und schau was den RAM frisst mit "top"
@apollon77 Am Ende ging der OOM Loop ne ganze Weile gut aber dann
2021-03-19 16:31:52.312 - [31merror[39m: host.iomaster-Server Cannot load /opt/iobroker/iobroker-data/objects.json: /opt/iobroker/iobroker-data/objects.json: Unexpected end of JSON input. Try last Backup!
2021-03-19 16:31:52.315 - [31merror[39m: host.iomaster-Server Cannot load /opt/iobroker/iobroker-data/objects.json.bak: Database file /opt/iobroker/iobroker-data/objects.json.bak does not exists.. Continue with empty dataset!Und damit wars schluss
-
-
@apollon77 @amg_666
Da geht halt regelmäßig das RAM aus.
Da hilft nur mehr Hubraum.@thomas-braun Aber die Frage ist WARUM? :-) deswegen wa r ich bei ... iobroker stoppen und erstmal "top" schauen ohne das ioBroker läuft was da abgeht. Und dann kann man ja eine instanz nach der anderen weider einschalten. Irgendeine muss der RAM Fresser sein
-
@thomas-braun Aber die Frage ist WARUM? :-) deswegen wa r ich bei ... iobroker stoppen und erstmal "top" schauen ohne das ioBroker läuft was da abgeht. Und dann kann man ja eine instanz nach der anderen weider einschalten. Irgendeine muss der RAM Fresser sein
@apollon77 Bin ich dabei. Wobei ich
htopja bevorzuge. Sort (F6) auf RAM usage setzen.
@amg_666 Schalt den radar2 Adapter dann als letzten dazu. Derversautspammt das log file... :-)Und die Systeme würde ich auch alle auf den letzten Stand bringen. Da scheint noch ein älterer Kernel zu laufen.
-
@thomas-braun Aber die Frage ist WARUM? :-) deswegen wa r ich bei ... iobroker stoppen und erstmal "top" schauen ohne das ioBroker läuft was da abgeht. Und dann kann man ja eine instanz nach der anderen weider einschalten. Irgendeine muss der RAM Fresser sein
@apollon77 sagte in iobroker nach Neustart "tot":
Irgendeine muss der RAM Fresser sein
ich tippe um 02:00 auf backitup
@amg_666
passt das? -
@apollon77 Bin ich dabei. Wobei ich
htopja bevorzuge. Sort (F6) auf RAM usage setzen.
@amg_666 Schalt den radar2 Adapter dann als letzten dazu. Derversautspammt das log file... :-)Und die Systeme würde ich auch alle auf den letzten Stand bringen. Da scheint noch ein älterer Kernel zu laufen.
@thomas-braun sagte in iobroker nach Neustart "tot":
Und die Systeme würde ich auch alle auf den letzten Stand bringen. Da scheint noch ein älterer Kernel zu laufen.
lohnt das noch, wenn jetzt der NUC kommt?
-
@apollon77 sagte in iobroker nach Neustart "tot":
Irgendeine muss der RAM Fresser sein
ich tippe um 02:00 auf backitup
@amg_666
passt das?Ich sage
io.javascript.0
schwappt über. Unsauberes skript vermutlich. -
@thomas-braun sagte in iobroker nach Neustart "tot":
Und die Systeme würde ich auch alle auf den letzten Stand bringen. Da scheint noch ein älterer Kernel zu laufen.
lohnt das noch, wenn jetzt der NUC kommt?
@homoran sagte in iobroker nach Neustart "tot":
lohnt das noch, wenn jetzt der NUC kommt?
Was für ein NUC? Ich hab nix bestellt!11!!1
Aber ein aktuelles System lohnt sich IMMER. :-)
-
@apollon77 Bin ich dabei. Wobei ich
htopja bevorzuge. Sort (F6) auf RAM usage setzen.
@amg_666 Schalt den radar2 Adapter dann als letzten dazu. Derversautspammt das log file... :-)Und die Systeme würde ich auch alle auf den letzten Stand bringen. Da scheint noch ein älterer Kernel zu laufen.
@thomas-braun @apollon77 @Homoran
Danke, danke, danke
mit dem MiniHowTo hab ich ihn wieder ans Laufen bekommen. Was ich jetzt (noch) nicht verstehe ist folgendes, siehe Screenshot, freies RAM 34% und auf meiner VIS habe ich auch über den rpi2 Adapter die relevanten Infos zu den 3 Raspis angezeigt, mir ist da noch nie groß was aufgefallen. Kann es evtl auch an irgendwelchen Skripten liegen, die unsauber sind und deshalb das System "zufahren" ? Ich werd in jedem Fall für mehr Systempower sorgen, aber die Momentaufnahme sieht doch garnicht so kritisch aus oder?
Dass der zigbee Adapter gelb ist liegt an Fehlermeldungen, dass er den Stick nicht findet, ich stöpsel jetzt aber am Raspi erstmal nicht rum, reicht mir für heute :-)
-
@homoran sagte in iobroker nach Neustart "tot":
lohnt das noch, wenn jetzt der NUC kommt?
Was für ein NUC? Ich hab nix bestellt!11!!1
Aber ein aktuelles System lohnt sich IMMER. :-)
@thomas-braun sagte in iobroker nach Neustart "tot":
Ich hab nix bestellt!11!!1
nix du!
@amg_666 braucht einen Kleinbus, keinen smart
-
@apollon77 sagte in iobroker nach Neustart "tot":
Irgendeine muss der RAM Fresser sein
ich tippe um 02:00 auf backitup
@amg_666
passt das? -
@thomas-braun @apollon77 @Homoran
Danke, danke, danke
mit dem MiniHowTo hab ich ihn wieder ans Laufen bekommen. Was ich jetzt (noch) nicht verstehe ist folgendes, siehe Screenshot, freies RAM 34% und auf meiner VIS habe ich auch über den rpi2 Adapter die relevanten Infos zu den 3 Raspis angezeigt, mir ist da noch nie groß was aufgefallen. Kann es evtl auch an irgendwelchen Skripten liegen, die unsauber sind und deshalb das System "zufahren" ? Ich werd in jedem Fall für mehr Systempower sorgen, aber die Momentaufnahme sieht doch garnicht so kritisch aus oder?
Dass der zigbee Adapter gelb ist liegt an Fehlermeldungen, dass er den Stick nicht findet, ich stöpsel jetzt aber am Raspi erstmal nicht rum, reicht mir für heute :-)
@amg_666 sagte in iobroker nach Neustart "tot":
siehe Screenshot, freies RAM 34%
traue diesem Wert mal nicht zu sehr.
topoderhtopauf der Konsole sind da viel genauer, auch wenn das auch nur eine Momentaufnahme ist und ein scheduled Adapter erst RAM braucht, wenn er gestartet wird. Insbesondere backitup braucht da seeeehr viel@amg_666 sagte in iobroker nach Neustart "tot":
Kann es evtl auch an irgendwelchen Skripten liegen, die unsauber sind und deshalb das System "zufahren" ?
Klar:
@thomas-braun sagte in iobroker nach Neustart "tot":
io.javascript.0
schwappt über. Unsauberes skript vermutlich. -
@amg_666 sagte in iobroker nach Neustart "tot":
1:30 Homematic Backup
das ist klein. -> kein Schaden
@amg_666 sagte in iobroker nach Neustart "tot":
2:00 Uhr iobroker Systembackup
Zeitpunkt des ersten OOM (Out Of Memory)
-
@apollon77 Bin ich dabei. Wobei ich
htopja bevorzuge. Sort (F6) auf RAM usage setzen.
@amg_666 Schalt den radar2 Adapter dann als letzten dazu. Derversautspammt das log file... :-)Und die Systeme würde ich auch alle auf den letzten Stand bringen. Da scheint noch ein älterer Kernel zu laufen.
@thomas-braun "Und die Systeme würde ich auch alle auf den letzten Stand bringen."
???
js-controller 3.2.16
node-js 12.20.1
npm 6.14.10
auf allen 3 Raspiradar nervt nur rum weil ich hier momentan Probleme mit bluetooth habe bzw auch das wlan manchmal etwas wacklig ist, ich kann den ja sonst auch auf loglevel error setzen (?)
-
@thomas-braun "Und die Systeme würde ich auch alle auf den letzten Stand bringen."
???
js-controller 3.2.16
node-js 12.20.1
npm 6.14.10
auf allen 3 Raspiradar nervt nur rum weil ich hier momentan Probleme mit bluetooth habe bzw auch das wlan manchmal etwas wacklig ist, ich kann den ja sonst auch auf loglevel error setzen (?)
@amg_666
Ich spreche da vom Betriebssystem, nicht vom ioBroker.
90% der Einträge im syslog stammen vom radar2, bzw. den Programmen, die der da ranzieht.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden