Hauptmenü

seltsamer Absturz

Begonnen von Navigator, 24 September 2014, 20:38:05

Vorheriges Thema - Nächstes Thema

Navigator

...gestern ist mir nach einem fhem update, dieses irgendwie festgefahren, was mir eigentlich noch nie vorgefallen ist. also eigentlich erst diese nacht. heute früh wurden erst mal keine schaltaktionen durchgeführt und auch der webclient war auf keinem port erreichbar. beim blick auf den cubie machte sich dann doch verwunderung breit. der fhem prozess war nicht mehr zu finden und trotzdem wurden die logfiles noch weiter mit daten gefüttert. wie kann das sein?  einzige fehlermeldung die ich finden konnte, war ein langer freeze und der besetzte telnetport. den fhem prozess beenden und neu starten braucht nichts, am ende nur ein neustart des cubies. eigentlich wollte ich letzteres vermeiden und mit hilfe des forums den fehler eingrenzen, aber früh im dunkeln sitzen, das ist nicht zweckmässig. man hat immer ein ungutes bauchgefühl, wenn irgendwo sich ein fehler eingeschlichen hat und man diesen nicht lokalisieren kann.


P.A.Trick

Den Telnet Fehler hatte ich heute auch nach speichern der fhem.cfg und dann auch einen Absturz! Im Log standen sonst keine Hinweise!
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

herrmannj

Hi,

wann in etwa hast Du den Neustart versucht ?

Der perfmon hat gegen 6:19 den Start eines freeze registriert der bis 6:34 dauerte, in dieser Zeit muss der Prozess durchgehend da gewesen sein.
Trotzdem (oder vermutlich weil) wurde um 6:26 und 6:31 jeweils ein weiterer fhem Prozess gestartet (versucht zu starten).

Der Neustart (cubie) war vermutlich nach 6:34 (screenshot) ??

viele Grüße
Jörg

Navigator

Hallo,

gegen 6:19 als der Freeze frestgestellt wurde, müsste die erste morgentliche Aktion stattgefunden haben, in Form von Bewegung und damit verbundenen Aktionen. Weil dies ausblieb und ich den Webclienten nicht erreichten konnte habe ich in den Prozess gesucht und nicht finden können. Hab ich ihn doch übersehen? Kann ich mir nur schwer vorstellen. Ich bin dann davon ausgegengen, daß dieser beendent wurde und habe wohl fhem dann ein zweites mal gestartet. Das war dann wohl 6.26 Uhr. Was passiert eigentlich bei so einem Versuch? Kommt daher der Telnetfehler? Danach habe ich den Prozess noch mal versucht zu beenden, wobei ich dann den Vorgang killen musste, weil er im Terminal nicht abgeschlossen wurde. Gegen 6.50 hab ich dann den Cubie komplett neugestartet. Den Fehler des notifys "N_Autoanwesenheit" ist bis dahin und seither auch nie aufgetreten.
Am Wochenende hab ich einen neuen Kernel eingespielt, vllt zwickt der ja an ein oder anderes Stelle.

Hier nochmal das komplette Log..


herrmannj

Hi,

der fhem prozess lebte noch, lag aber 15 Minuten im Koma und hat sich wohl auch nie ganz von dem Schock erholt. :-)

Sieht ganz nach einem IO Timeout aus (IP), im nachhinein kann man aber nicht sagen wer das war. Hoffen wir das es eine Eintagsfliege bleibt. Wer hätte um 6:19 auf IP schreiben sollen ?

Kannst ja sicherheitshalber mal den freien Speicher (RAM) im Auge behalten. Da Du den Kernel getauscht hast  wirst Du wissen wie :-) Wenn Du viel Lust hast kannst Du Dir ja ein script dazu machen. Soweit ich weiß dürfte aber auch sysmon von Hexenmeister gut dafür gehen.

vg
Jörg

Hollo

Zitat von: Dittel am 25 September 2014, 15:35:52...müsste die erste morgentliche Aktion stattgefunden haben, in Form von Bewegung und damit verbundenen Aktionen. Weil dies ausblieb und ich den Webclienten nicht erreichten konnte habe ich in den Prozess gesucht und nicht finden können...
Da schließe ich mich mal an. Sah bei mir identisch aus, allerdings am frühen Abend als ich nach Hause kam.
Habe dann fhem neugestartet, einen Moment gewartet und anschließend meinen HomeStatus manuell gewechselt. Gleiches Verhalten... erste Aktionen starteten und dann hing das ganze System. Raspi rebootet und wiederholt, gleiches Verhalten.
Ich habe dann das Restoredir vom 22.09. rüberkopiert und seitdem läuft das System (subjektiv) wieder. Configs hatte ich in der Zwischenzeit definitiv nichts verändert.
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

herrmannj


Wie (Modul???) realisierst Du den "HomeStatus" ?
wer schriebt dabei bei Dir auf TCP ? (Tablets, Radios etc ?)


vg
Jörg

Hollo

HomeStatus ist ein Dummy, der über notify Funktionen in 99_myUtils aufruft.
Über TCP gehen dabei die Befehle an meine dBox, um z.B. von standby ein und auf TV umzuschalten und die Lautstärke auf einen bestimmten Wert zu stellen.
Genau das wurde dann aber nicht mehr ausgeführt.

FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

Puschel74

Hallo,

Netzwerkverbindungen sind aber stabil?
Nur mal so ins Blaue geraten.

Grüße
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

Hollo

Bin ich zumindest von ausgegangen.
Die betroffenen Komponenten waren alle netzwerkseitig mit Kabel angeschlossen (also kein WLAN) und im selben Netz.
Habe leider nicht kontrolliert, ob die HM-Befehle sauber umgesetzt wurden; läuft über einen HMLAN.

Werde heute mal updaten und erneut beobachten.
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"