UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[wendy2702]

@wolfgangfb Was ist überhaupt alles auf dem Pi installiert ?

[WolfgangFB]

Mit dmesg -T kommt eine ewig lange Liste, die aber nicht den Reboot Zeitpunkt beinhalten.
Was aber ein paarmal auftritt ist folgender Part:

Di Apr 20 17:19:50 2021] [  12060]  1001 12060     1177      156    24576        0             0 ping
[Di Apr 20 17:19:50 2021] [  12062]     0 12062       98        1    24576        0             0 resolvconf
[Di Apr 20 17:19:50 2021] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=node,pid=9736,uid=1001
[Di Apr 20 17:19:50 2021] Out of memory: Killed process 9736 (node) total-vm:1223992kB, anon-rss:1090996kB, file-rss:7692kB, shmem-rss:0kB, UID:1001 pgtables:3496kB oom_score_adj:0
[Di Apr 20 17:19:50 2021] oom_reaper: reaped process 9736 (node), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Das habe ich durch ein fehlerhaftes Javaskript verursacht bei dem ich nicht beachtet habe, dass Variablen in Funktionen nicht lokal sind und damit jedes mal die Javaskript Instanz gekillt habe. Ob das zum Reboot Zeitpunkt auch der Fall war weiß ich nicht.

Der Raspi ist mein Bastelrechner, deshalb auch der vnc-Server mit dem ich einfach alles mögliche ausprobiere.

[Thomas Braun]

@wolfgangfb
Dir geht halt der Speicher aus.
Bedingt durch die Kombination unsaubere skripte und laufender X-Server.
Da kann man dir nicht weiterhelfen, wenn du die Dinge nicht anpasst.
Warum auf einem Bastelrechner ein Desktop per VNC laufen muss erschließt sich mir auch nicht. Basteln kann man auch ohne Desktop und VNC.

[Thomas Braun]

@apollon77

Mir ist eben etwas in meinem eigenen Log aufgefallen, das ich mir nicht erklären kann, aber hiermit etwas zu tun haben könnte.

Log sagt:

2021-05-03 18:47:12.973  - error: host.chet-Server Cannot move /opt/iobroker/iobroker-data/objects.json.new to /opt/iobroker/iobroker-data/objects.json: ENOENT: no such file or directory, stat '/opt/iobroker/iobroker-data/objects.json.new'. Try direct write as fallback

Das ist aber nicht richtig, denke ich. Die Ziel-Datei gibt es nämlich:

pi@chet:~ $ ls -la /opt/iobroker/iobroker-data/objects.json
objects.json      objects.json.bak
pi@chet:~ $ ls -la /opt/iobroker/iobroker-data/objects.json
-rw-rw-r--+ 1 iobroker iobroker 10767373 Mai  3 18:53 /opt/iobroker/iobroker-data/objects.json

(Gut, die objects.json.new gibt es nicht (mehr?).

[apollon77]

@thomas-braun Sehr komisch. SOlche Fälle hab ich in Logs mal gesehen ... aber der Grund ist unklar. so wie der code abläuftkann das an sich nur passieren wenn dinge parallel laufen ... ich schaue nochmal code an

[Thomas Braun]

@apollon77

Ich hab jetzt mal im syslog geschaut. Da ist eigentlich nix wildes drin. Der Zufallszahlengenerator hat ungefähr zu der Zeit gepokert:

May  3 18:47:10 chet rngd[385]: stats: bits received from HRNG source: 80064
May  3 18:47:10 chet rngd[385]: stats: bits sent to kernel pool: 33824
May  3 18:47:10 chet rngd[385]: stats: entropy added to kernel pool: 33824
May  3 18:47:10 chet rngd[385]: stats: FIPS 140-2 successes: 4
May  3 18:47:10 chet rngd[385]: stats: FIPS 140-2 failures: 0
May  3 18:47:10 chet rngd[385]: stats: FIPS 140-2(2001-10-10) Monobit: 0
May  3 18:47:10 chet rngd[385]: stats: FIPS 140-2(2001-10-10) Poker: 0
May  3 18:47:10 chet rngd[385]: stats: FIPS 140-2(2001-10-10) Runs: 0
May  3 18:47:10 chet rngd[385]: stats: FIPS 140-2(2001-10-10) Long run: 0
May  3 18:47:10 chet rngd[385]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
May  3 18:47:10 chet rngd[385]: stats: HRNG source speed: (min=348.393; avg=433.922; max=572.361)Kibits/s
May  3 18:47:10 chet rngd[385]: stats: FIPS tests speed: (min=8.859; avg=11.454; max=14.593)Mibits/s
May  3 18:47:10 chet rngd[385]: stats: Lowest ready-buffers level: 2
May  3 18:47:10 chet rngd[385]: stats: Entropy starvations: 0
May  3 18:47:10 chet rngd[385]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us

[apollon77]

@thomas-braun ALso diese .new ist der "neue" Weg seit Controller 3.3 um zu verhindern das ein Crash während dem Schreiben der Datei zu kaputten JSONs führt. Wir schreiben in .new und dann benennen wir die nur um und löschen die alte.

Dieser Fehler - unter der premisse das vorher kein Fehler vom schreiben kam - kann an sich nur bedeuten das eine Schreibaktion der 10MB so lange gedauert hat das parallel ne zweite kam und es so zur konstellation kam das ein rename ausgeführt wurde und daher das zwite warten musste.

Was ist es denn für ein System? SD Karte? Du noch ne IDee?

Das einzige was mir einfällt das ich explizit das schreiben blocke wenn noch eine Schreibaktion läuft. Das sollte solche Parallelitäten ausschliessen

Das würde dann heissen das es viele Objektänderungen gab und die Karte >5s gebraucht hat um das new zu schreiben, sodass in der zwischenzeit ein zweiter Prozess gestartet hat zu schreiben und die sich dann komisch überlappt haben (aber geht das zwei mal gleiches File zum schreiben öffnen ... dachte wird eher gelockt ... hm ....)

[Thomas Braun]

@apollon77
Ist ein Raspi 4 mit 8 GB auf einer 32GB-SD-Karte, die auch keine Ausfallerscheinungen zeigt, soweit ich sehe.

[Mo Mai  3 17:47:03 2021] mmc1: new high speed SDIO card at address 0001
[Mo Mai  3 17:47:03 2021] mmc0: new ultra high speed DDR50 SDHC card at address aaaa

(Zufällig(?) genau eine Stunde zuvor ein Reboot gemacht.)

Und eigentlich meine ich das System recht schlank zu haben, das sollte sich mehr oder weniger langweilen.

Objekte: 4668, Zustände: 3998
sagt mir der Objekte-Reiter. Das sollte ja eigentlich noch nicht kritsch sein.

pi@chet:~ $ iobroker status
iobroker is running on this host.

Objects type: file
States  type: redis

[apollon77]

@thomas-braun Danke, wir haben geschaut und eine Stelle optimiert die potentiell parallele DB Speichern-Fälle erzeugen konnte. Kommt in 3.3.8 später

[Thomas Braun]

@apollon77
Aber nich wieder meine Beleuchtung ausknipsen, wie mit dem 3.3.6, okay? :-D

[apollon77]

@thomas-braun Ach menno ... gönnst mir aber auch gar keinen Spass ;-)

Eine Bitte mit der 3.3.8 - da wir dort was am Speicherverhalten ändern (an sich unkritisch aber sicher ist sicher) bitte verifizieren nach dem Update das die beiden jsons danach regelmäßig geschrieben werden. Erste Tests bei mir waren ok.

[apollon77]

3.3.8 (2021-05-03)

• (Apollon77/foxriver76) Optimize Database storage behaviour for file database
• (foxriver76) change default behaviour of cli update command -> only list installed, allow --all as parameter to see all again

[Thomas Braun]

@apollon77

Kurztest: Beide Dateien werden regelmäßig (Timestamp etwa minütlich) geschrieben. Ist das normal oder richtig in der Häufigkeit? Hab das nicht im Blick wie es sein soll.

[apollon77]

@thomas-braun Naja liegt an den Önderungen an den Daten und dann dem eingestellten Schreibdelay (States 30s, Objects 5s) ... also ja. kann hinkommen

[Thomas Braun]

@apollon77
States hab ich auf redis laufen.
Objects auf file.

Aber warum muss man die Objects überhaupt so häufig speichern? Ich dachte die ändern sich in einem 'gesetzten' System kaum noch.

[apollon77]

@thomas-braun Geht nicht um "Häufigkeit". Die 5s heisst: 5s nach einem Change speichern wir. An sich ändern sich Objekte nicht so wirklich oft (war zumindestens bisher so), sind aber wenn "wichtige Informationen". Daher war es immer "Wenn sich mal ein Objekt ändert dann sollte man das zeitnah persistieren". Wenn es keine Objekt-Änderung gibt wird aiuch nix gespeichert!

Inzwischen hat sich aber das Thema weiterentwickelt und Objekte ändern sich häufiger - auch wenn es nur der Zeitstempel ist und das macht das gerade strange. Da Optimieren wir momentan und mit den controller Versionen.

[rehmosch]

Vielen Dank für diesen Beitrag. Habe den ganzen Vormittag damit verbracht ioBROKER "wieder einmal" zum Laufen zu bekommen. Das letzte mal war der Dateienschwund vor einem halben Jahr (SD Karte) und hätte nicht gedacht das es dieses Mal (SSD) wieder passieren würde.

Wenn ich es hier im thread richtig verstanden habe, dann liegt es am Netzteil?

Danke nochmal für diesen Thread!

[Homoran]

@rehmosch sagte in Mini-HowTo: Cannot find view "system" for search "host":

Wenn ich es hier im thread richtig verstanden habe, dann liegt es am Netzteil?

das Netzteil ist eine mögliche Variante.

ioBroker schreibt sehr viele Daten, tlw. in sehr kurzen Abständen.
Wenn es genau in dem Moment zu einem Problem kommt ist die Datenbank defekt.

Ein under-voltage wäre ein solches Problem.

[apollon77]

@rehmosch AM Ende schau mal in /var/log/syslog zum relevanten Zeitpunkt ...

[BananaJoe]

@homoran sagte in Mini-HowTo: Cannot find view "system" for search "host":

@rehmosch sagte in Mini-HowTo: Cannot find view "system" for search "host":

Wenn ich es hier im thread richtig verstanden habe, dann liegt es am Netzteil?

Ein under-voltage wäre ein solches Problem.

Eine under-voltage-Meldung solltest du nach dem booten in den Logs finden bzw. diesen Befehl ausführen:

/opt/vc/bin/vcgencmd get_throttled

Wenn da dann nicht

throttled=0x0

steht hast du ein Netzteilproblem.