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

[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.

[rehmosch]

@bananajoe said in Mini-HowTo: Cannot find view "system" for search "host":

/opt/vc/bin/vcgencmd get_throttled

danke

throttled=0x50000

[BananaJoe]

@rehmosch du brauchts ein neues Netzteil! Mein Raspi am 3D Drucker hatte auch undervoltage und ich hatte mich schon gewundert warum der bei Kurven so ruckelt ...

Hab ein offizielles Originalnetzteil gekauft und die Probleme waren weg

[rehmosch]

@bananajoe danke! Mann das erklärt so vieles ;( hast du einen Link?

Ach ja, hab ein Raspberry 4 / 4 GB RAM mit usbc SSD (128 GB) dran.

Danke