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

[apollon77]

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

546038178 Jul 23 22:13 objects.jsonl

Ok ,, die ist recht groß UND es gibt eine objects.jsonl.lock ... die bitte mal löschen (letztere)

Damit wäre ich bei der Variante mal für einen Start den timeout bei objects hochzusetzen.-

Bei gestoppptem iobroker mal /opt/iobroker/iobroker-data/iobroker.json editieren und dort unter objects und am besten auch states (siehe https://forum.iobroker.net/topic/54570/gelöst-iob-update-no-connection-to-databases-possible).

Dann nach der Änderung mach mal nur "iob list instances" oder so. Geht das? Wenn ja wie groß ist die objects.jsonl dann?

Und stelle sicher das du js-controller 4.0.23 oder so hast ... also was aktuelles ... Du hast nicht gesagt was Du hast

[David G.]

Heute hatte ich die besagt Meldung auch zum ersten mal im Log.
Mein System war heute morgen nicht mehr erreichbar. Auch nicht per ssh erreichbar.

Nach einem reboot war der Fehler der letzte im ioBroker Log bevor er offline war.
Vorher gab es noch eine Meldung vom js-Controller.
Finde aber nicht, wo er beendet worden sein soll.

2022-09-01 00:20:54.747 - info: host.pi iobroker.js-controller version 4.0.23 js-controller starting
2022-09-01 00:20:54.755 - info: host.pi Copyright (c) 2014-2022 bluefox, 2014 hobbyquaker
2022-09-01 00:20:54.756 - info: host.pi hostname: pi, node: v16.17.0
2022-09-01 00:20:54.757 - info: host.pi ip addresses:
2022-09-01 00:20:56.857 - error: host.pi-Server Cannot start inMem-objects on port 9001: Failed to lock DB file "/opt/iobroker/iobroker-data/objects.jsonl"!

pi@pi:~ $ iob v
4.0.23
pi@pi:~ $ node -v
v16.17.0
pi@pi:~ $ npm -v
8.15.0
pi@pi:~ $

[apollon77]

@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

[Rene 3]

@apollon77 Hi, ich habe das gleiche Problem seit 28.08.2022 mit einem Raspi4 und einer SSD. Die Datei objects.jsonl.lock kann nicht gelöscht werden, wenn der iobroker läuft, wird sie bei mir gleich wieder erzeugt. Sie ist nur 4096 Byte groß ???

[apollon77]

@rene-3 Laaaangsam ... Ja diese Datei existiert sobald iobroker löuft oder irgendein prozess die Datenbank anbietet - weil es verhindert werden muss das ein weiterer prozess die DB öffnet. Das ist komplett korrekt so! Also das das File da ist ist per se kein Problem!

Man muss jetzt schauen was genau das problem ist wenn Ihr diesenF ehler bekommt weil dann irgendetwas versucht die DB nochmals zu öffnen.

Daher gleiche Fragen wie oben bitte beantworten!

[Rene 3]

@apollon77 ... die letzten Einträge in /var/log/syslog sehen bei mir so aus.

[apollon77]

@rene-3 1.) Keine Grafiken, bitte text
2.) mmeeehhhrrrrrrr Log :-)

Spontan sieht das nach nem Reboot aus ... Warumm ... mehr log

[Rene 3]

@apollon77 ... da steht leider nicht mehr im Log ( /var/log/syslog ). Während bis zum 27.08.2022 immer wieder nur die Time Synchronisation hier regelmäßig eingetragen wurde, ist das ja seltsamerweise ab dem 28.08.2022 nicht mehr so zu sehen. Oder meinst du jetzt andere Logs ?
iob fix scheint durchzulaufen und wird "erfolgreich" beendet aber alles andere scheitert.
Komme nur über vnc an den Rasberrypi - über den Browser ist nichts mehr erreichbar.

[Thomas Braun]

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

Komme nur über vnc an den Rasberrypi

Per ssh...
VNC ist "verboten"!
Desktop ausschalten, kostet dich eh nur unnütz Ressourcen, die du anderweitig eher gebrauchen kannst.

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