openWB Forum

openWB hat geschrieben: ↑Mo Mär 01, 2021 6:23 am Hierfür müsste erstmal ein reproduzierbares Problem bestehen. Bis dato konnte das nicht nachgestellt werden. Damit gestaltet sich ein Bugfix schwierig.

Ohne irgendwas dran zu tun wird das wohl auch schwierig rauszufinden.

Nach meinem Verständnis sind alle Logdaten in der Ramdisk, also kommen wir da nach eine Reboot nicht dran. Wie wäre es zur Suche der Fehlerursache dies temporär umzustellen? Wir könnten statt der Ramdisk ein Netzwerkshare oder einen USB-Stick nutzen. Also den mount-Punkt in der `/etc/fstab` einfach umleiten auf etwas entsprechendes und dann beim reboot (in der initRamdisk.sh) die alten Daten wegspeichern (sowas wie `tar -czf ramdisk-archive-$(date '+%Y-%m-%d').tar.gz .`). Dann könnten wir uns nach so einem Ereignis mal ansehen was der letzte bekannte Zustand war und ob irgendwas daran vielleicht auffällig ist.

Vielleicht verbirgt sich aber auch was in den System-Logs. So was man üblicherweise in /var/log findet. Das landet ja scheinbar nicht in der Ramdisk und müsste nach einem Reboot noch da sein...

Die openWB.log existiert auch persistent in /var/log und wird nur in die Ramdisk verlinkt.
Zumindest temporär könnte man das löschen der openWB.log in der Reboot.sh und in der shutdown.sh entfernen. Housekeeping wird auf die Datei ja in der cronnightly gemacht.

VG
Det

Also ichhabe gerade noch mal in nach der openWB.log geschaut. Sie wird bei einem Reboot und bei einem Shutdown neu angelegt. Nach einem Absturz bzw. Kaltstart muss die Datei noch da sein und sollte Inhalt haben, sodass auch ein Support File erzeugt werden kann. Hab das gerade auch mit meinem Raspi hier getestet.
Ich habe auch ein kleines Script pingcheck geschrieben, welches alle 5 Minunten versucht das Gateway anzupingen. Geht das schief, wird ein Eintrag in die openWB.log geschrieben, mit Gateway IP und Device, sodass ersichtlich wird, ob LAN oder WLAN.

Was ich bei einem meiner Raspis auch schon hatte mit FHEM, war eine defekte SD Karte. Der Raspi lief immer mehrere Tage ohne Probleme und irgendwann hat er sich dann hingestellt und war nicht mehr erreichbar. Nichts konkretes in den Logs zu finden. Karte kopiert auf eine neue SD und jetzt ist seit sicher 8-9 Monaten kein einziger Ausfall mehr gewesen. Also evtl. mal in diese Richtung denken.

Das pingchecker Script schicke ich per PR ins Git.

VG
Det

Ab der aktuellen Nightly ist der Pingcheck aktiv. Alle 5 Minuten wird versucht das Gateway zu erreichen. Wenn es nich funktioniert wird ein Eintrag in das Logfile geschrieben. Wenn also eure Boxen wieder mal aussteigen, bitte nach dem Hard Reset schauen, ob es Einträge im Debug Log gibt.

VG
Det

derNeueDet hat geschrieben: ↑Mi Mär 03, 2021 3:28 pmAb der aktuellen Nightly ist der Pingcheck aktiv. Alle 5 Minuten wird versucht das Gateway zu erreichen. Wenn es nich funktioniert wird ein Eintrag in das Logfile geschrieben.

OK, dann update ich gleich mal auf das "Nightly". Mir ist aber noch nicht ganz klar was ich daraus erfahre...? Also gut, ich sehe dann ob das Ping-Script noch lief, was dann aber erstaunlich wäre?

derNeueDet hat geschrieben: ↑Mi Mär 03, 2021 3:28 pmWenn also eure Boxen wieder mal aussteigen, bitte nach dem Hard Reset schauen, ob es Einträge im Debug Log gibt.

Wie kommt man als normalsterblicher an das Debug-Log?

Du siehst aus dem Log, ob der Raspi noch Verbindung hatte zur Aussenwelt. Das ist im Netzwerk Bereich sxhon fast die ganze Miete....

Wie kommt man als normalsterblicher an das Debug-Log?

Status -> Debug Log

openWB hat geschrieben: ↑Mi Mär 03, 2021 4:27 pm Status -> Debug Log

Ach cool, was da alles steht... Und das Menü habe ich die ganze Zeit übersehen.

Mir ist aber noch nicht ganz klar was ich daraus erfahre...? Also gut, ich sehe dann ob das Ping-Script noch lief, was dann aber erstaunlich wäre?

Nachdem die Boxen zumindest teilweise noch geladen haben, vermute ich, dass die Programme intern noch gelaufen sind, und nur die Box nicht mehr erreichbar war.
Das Gateway ist euer Router und wenn dieser nicht erreicht wird, dann wird ein Eintrag in das Debug log geschrieben
Es wird die Gateway Adresse und das Device also eth0 LAN oder wlan0 für WLAN eingetragen. Das kann auch verwendet werden, um zu erkennen ob die WLAN Verbindung auch wirklich stabil ist. Dadurch dass es in das Debug Log geschrieben wird, wird es bei einer Support Meldung auch an den Support übermittelt.
Mir hilft das auch, da ich meine Box per WLAN verbunden habe und meine Netzstabilität damit auch überwache und im Zweifel noch weitere Access Points oder spezielle Antennen anbringe.

VG
Det

Was machen denn eure openWB jetzt?
Gibt es Timeouts wenn die ooenWB versucht das Gateway zu erreichen?

VG
Det