Neues YouTube-Video: Visualisierung im Devices-Adapter

[Thomas Braun]

@amg_666
Gib uns doch mal bitte die Dateien
/var/log/syslog
/opt/iobroker/log/iobroker.current.log

Und der Zeitpunkt des Reboot wird dann noch benötigt.

[apollon77]

Ich zähle 13 Instanzen und dabei einige potentiell größere wie snmp und sowas... wieviel RAM hast Du denn?

[apollon77]

@thomas-braun sagte in iobroker nach Neustart "tot":

/opt/iobroker/log/iobroker.current.log

Current log gabs schon oben!

[amg_666]

@apollon77 13 Instanzen müssten es locker sein, ist iwe gesagt ein Multihost System und ich hab die Adapter/Instanzen mehr oder weniger gleichmäßig verteilt. In den PIs sind jeweils 32GB Karten.

@Thomas-Braun Syslog:
syslog

[Homoran]

@apollon77 erster oom-killer gum 02:00
ich nehme an, da läuft backitup

dann passend zu deiner Vorhersage:
Mar 19 11:03:36 iomaster kernel: [251223.920004] node invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0

[apollon77]

@amg_666 Jupp ...

Mar 19 11:03:36 iomaster kernel: [251223.920004] node invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Mar 19 11:03:36 iomaster kernel: [251223.920872] Out of memory: Killed process 19776 (node) total-vm:231148kB, anon-rss:117040kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:562kB oom_score_adj:0

Mar 19 11:06:11 iomaster kernel: [251378.255863] Out of memory: Killed process 19629 (node) total-vm:282056kB, anon-rss:160004kB, file-rss:720kB, shmem-rss:0kB, UID:1001 pgtables:622kB oom_score_adj:0

[apollon77]

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

[amg_666]

@apollon77 2 Fragen: 1. Wie genau stelle ich das wieder her? 2. wenn 13 Instanzen zuviel sind würde eine größere SD Karte Abhilfe schaffen, oder?

[Homoran]

@amg_666 sagte in iobroker nach Neustart "tot":

wenn 13 Instanzen zuviel sind würde eine größere SD Karte Abhilfe schaffen, oder?

nein!

das RAM wahrscheinlichj hast du nur 1GB) reicht nicht

Es fehlt noch die Info wann genau du rebootet hattest

[amg_666]

@homoran Ja klar, Denkfehler von mir, die PIs haben 1GB... Reboot weiss ich nicht mehr, müsste aber so gegen 15:45 gewesen sein

[apollon77]

@amg_666 Jeder iobroker prozess hat sagen wir 50MB ... 13 Adapter plus controller ... 700MB allein dafür ... jetzt ist die Frage was noch drauf läuft ...

[Homoran]

@apollon77 sagte in iobroker nach Neustart "tot":

13 Adapter plus controller ..

aber die sind doch auf den 3 Hosts verteilt!

@amg_666
oder?

[amg_666]

@apollon77 Wie meisnt du das? Auf den PIs läuft "nur" iobroker (und vis edit und flot und auf einem Slave)

[amg_666]

@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

[Thomas Braun]

@apollon77 @amg_666
Da geht halt regelmäßig das RAM aus.
Da hilft nur mehr Hubraum.

[amg_666]

@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]

@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

[apollon77]

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]

@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

[apollon77]

@apollon77 Am Ende ging der OOM Loop ne ganze Weile gut aber dann

2021-03-19 16:31:52.312 - error: 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 - error: 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