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

[Rene 3]

@thomas-braun upps ::disappointed: :disappointed:

[David G.]

@apollon77 sagte in Server Cannot start inMem-objects on port 9001:

@david-g Am Ende ist mehr Interessant was DAVOR passiert ist. Also wie hört das Log auf wo es stehen geblieben ist? Was steht ggf in /var/log/syslog? Wie gross sind die Dateien /opt/iobroker/iobroker-data/*.jsonl ?

Ingo

So, hab jetzt mal alles rausgesucht.
Anbei die beiden Logs ab Mitternacht bis zum Absturz um 0:20 und dem ersten Logeintrag nach dem reboot um 6:02.

iobroker.2022-09-01.log (hoffe habe alles an persönlichen Daten gefunden und ersetzt ^^)

syslog.txt
Hier fällt mir auf:

Sep  1 00:20:56 pi systemd[1]: iobroker.service: Main process exited, code=exited, status=24/n/a
Sep  1 00:20:56 pi systemd[1]: iobroker.service: Failed with result 'exit-code'.

Größe der jsonl:
objects.jsonl 26,6MB
states.jsonl 41,2MB

Laut History waren ausreichend Systemressourcen vorhanden.
Ram und CPU waren kaum ausgelastet.

[apollon77]

@david-g Also ein Log wie dieses was nach einem Log mit 00:44 dann plötzloc mit fakehwclock und einer alten Uhrzeit startet bedeutet nprmalerweise das das system neu gestartet wurde. Also Power war weg oder irgendein so harter kernel crash das es ohne log zum reboot geführt hat.

Sieht man auch an den folgenden Log Ausgaben.

Und danach gab es dann den Fehler. Ok also jetzt schauen warum.
Wenn Du "iob stop" und "iob start" mchst tut es dann wieder? oder kommt immer noch der Fehler?
Falls ja, dann bitte "iob stop "und schauen das er wirlich aus ist und aus bleibt. Dann was sagt "iob status"?

[David G.]

@apollon77

Seit dem crash läuft das System stabil.
Musste es leider vom Strom trennen, da kein Zugriff mehr möglich war (habe leider keinen Bildschirm zu Verfügung am Pi), kein Ping kein ssh.

Ein reboot klappt ohne Probleme. Samt Start vom iobroker.

Dann war es ja vermutlich keine "Fehlfunktion" vom iobroker.
Wenn sowas nochmal passiert, Vergleiche ich mal die logs (hatte ich eigentlich erst einmal, vor 3 Wochen oder so).

[apollon77]

@david-g Ok, ich hab eine Vermutung die ich gerade prüfe ... die vllt auch genrell hier und da in soclhen Situationen probleme erklären kann. Hintergrund ist die Uhrzeit ... Wenn das lock File von 00:44:00 ist weil es da gecrasht ist und danach ist de Zeit aber 00:20:00 ... dann erkennt vermutlich die Library das Lockfile als "gültig" und nicht als Stale ... erst quasi 24 Minuten später wäre das valide

[David G.]

@apollon77
Hab zwar keine Ahnung von, klingt aber plausibel ^^.

Hatte mich auch gewundert, warum die telegram mit "restarting" so lange nach dem crash gekommen ist.
Im Log war mir das mit dem Zeitversatz nicht aufgefallen.

[apollon77]

@Thomas-Braun Wenn nochmal ein "jsonl lock file "fehler kommt mal die aktuelle uhrzeit mit dem timstamp des lock dirs vergleichen lassen ... Ich denke das das die Ursache ist

[Thomas Braun]

@apollon77
Sollte aber nur ein Problem bei Systemen ohne RTC sein.

[apollon77]

@thomas-braun Exakt.Ist aber ein weiterer Punkt zum "Abfragen beim User" bei solchen Issues den wir bisher nicht auf dem Radar hatten :-)

[Thomas Braun]

@apollon77

Zeitreisen sind auch immer doof. Frag mal Marty McFly.

[apollon77]

@thomas-braun :grinning:

[Thomas Braun]

@david-g

Interessant wäre auch ein syslog von der Zeit. Vielleicht sieht man da was zum Flipper führt.

[David G.]

@thomas-braun

Ist das eine andere Datei?

Das gepostete syslog ist ja von 0 Uhr bis zum reboot morgens.

[Thomas Braun]

@david-g

Sorry, hatte ich übersehen. Nur das iobroker.log gefunden.
Im sys.log steht nix wirklich erhellendes drin.
Vielleicht in einer der /var/log/kern.log ?

[apollon77]

@thomas-braun sieht mir nach nem Power-outage aus, ggf Netzteil prüfen

[Thomas Braun]

@apollon77

Aber da läuft eine USV...
Gut, wenn das Netzteil einen weg hat...

[David G.]

@thomas-braun sagte in Server Cannot start inMem-objects on port 9001:

@david-g

Sorry, hatte ich übersehen. Nur das iobroker.log gefunden.
Im sys.log steht nix wirklich erhellendes drin.
Vielleicht in einer der /var/log/kern.log ?

Kann es leider grad nicht kürzen.
kern.log

@apollon77 sagte in Server Cannot start inMem-objects on port 9001:

@thomas-braun sieht mir nach nem Power-outage aus, ggf Netzteil prüfen

Bestelle mal ein neues. Ist aber ein original Netzteil vom Raspberry.

[apollon77]

@thomas-braun ALso bei Kernel Panix oder sowas hab ich meistens mnoch komische Null Zeichen im Log gesehen ... aber hier ist da gar nix ... aber ja es ist definitiv ein Reboot.

[apollon77]

@david-g sieht man auch nix ... geht direkt quasi mit dem Reboot los

EDIT:
Und das hier sagt das auf jeden Fall was vorher nicht sauber war:

Sep  1 00:20:51 pi kernel: [    2.257844] EXT4-fs (sda2): INFO: recovery required on readonly filesystem
Sep  1 00:20:51 pi kernel: [    2.257887] EXT4-fs (sda2): write access will be enabled during recovery
Sep  1 00:20:51 pi kernel: [    2.489092] EXT4-fs (sda2): orphan cleanup on readonly fs
Sep  1 00:20:51 pi kernel: [    2.504177] EXT4-fs (sda2): 7 orphan inodes deleted
Sep  1 00:20:51 pi kernel: [    2.504220] EXT4-fs (sda2): recovery complete
Sep  1 00:20:51 pi kernel: [    2.511628] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.

Aber ja ... fals vorher das Filesystem auf Read only gegangen ist dann ist es ja klar das im log nix steht :-) Also vllt auch ein Filesystem issue

[Thomas Braun]

@apollon77

Da fehlt auch ein ganzer Tag:

Aug 30 17:03:57 pi kernel: [   31.832347] cam-dummy-reg: disabling
Sep  1 00:20:51 pi kernel: [    0.000000] Booting Linux on physical CPU 0x0

[Edit:] Kann aber sein, das kern.log ist nicht sooooo geschwätzig. Das hält auch schon mal lange den Rand