Hallo Zusammen,
ich habe ein Problem bei dem ich alleine zu keiner Lösung komme.
Bei mir lüft seit einigen Jahren ein Cubietruck als Server.
Dieser fungiert "nur" als FHEM und SAMBA Server.
Das ganze funktioniert zu 99% auch völlig problemlos.
Allerdings, jedes Jahr wenn ich über Weihnachten in den Winterurlaub fahre, stürzt der Cubietruck komplett ab.
Er ist dann auch nicht mehr per SSH zu erreichen.
Das ist natürlich ärgerlich, weil dann einiges an Steuerung nicht mehr funktioniert, und ich die (zuvor abgesenkte) Temperatur vor Heimkunft nicht mehr hochstellen kann.
Das ganze passiert immer im Winterurlaub, und manchmal auch unter-jährig. Insgesamt ca. 3 mal im Jahr.
Das Netzteil habe ich schon einmal getauscht, aktuell habe ich ein AMAZON 9Watt Netzteil im Einsatz.
Das hat aber keine Veränderung gebracht.
Würde mich über Ideen/Vorschläge freuen
Danke und Grüße
Dominik
Wenn das so selten passiert, wird es schwierig was zu finden. Kann ja alles sein, Hardware wie Software. Cubietruck hat ein Hardware-Watchdog, musst du natürlich etst aktivieren. Das eliminiert nicht die Ursache, löst aber erstmal das Problem, wenn auch mit einer Holzhammermethode.
Ich hatte "damals" mit dem Cubietruck auch das Problem, dass er gelegentlich komplett eingefroren ist. Da half dann immer nur ein kompletter Neustart des Cubietruck über Reset direkt am Gerät.
Auch diverse Kernelupdates und das abschalten des Overclocking (btw. das könntest du mal noch versuchen, falls noch nicht geschehen) haben nichts geholfen. Das war dann letztendlich für mich auch der Grund einen "richtigen" Rechner für mein produktives FHEM einzusetzen.
Wegen der Taktfrequenzgeschichte kannst du dir mal folgenden Thread anschauen:
https://forum.fhem.de/index.php/topic,26992.0.html
Zum Thema Watchdog gibt es in folgendem Thread etwas:
https://forum.fhem.de/index.php?topic=54570.15
gb#
Super, danke euch, das hilft schon mal.
Das mit dem Watchdog schaue ich mir an.
Wenn das aber am Cubietruck liegt, dann steige ich vll auch um.
Überlege eh schon, dass ich das auf ein odroid xu4q umsteige.
Der hat dank besserer Leistung und USB 3 auch eine besser Performance als Fileserver, da ist der Cubietruck eh nicht sehr gut geeignet.
Grüße
Dominik
Zitat von: elDudereeno am 06 Januar 2018, 22:23:45
Super, danke euch, das hilft schon mal.
Das mit dem Watchdog schaue ich mir an.
Wenn das aber am Cubietruck liegt, dann steige ich vll auch um.
Überlege eh schon, dass ich das auf ein odroid xu4q umsteige.
Der hat dank besserer Leistung und USB 3 auch eine besser Performance als Fileserver, da ist der Cubietruck eh nicht sehr gut geeignet.
Grüße
Dominik
Schau mer mal was von der Performance übrigbleibt wenn die patches für spectre drin sind. :-(
Hab selbst den XU4Q Zuhause in Betrieb und den gerade wegen der Performance genommen.
Grüße
Schnitzelbrain
Zitat von: schnitzelbrain am 07 Januar 2018, 09:32:42
Schau mer mal was von der Performance übrigbleibt wenn die patches für spectre drin sind. :-(
Wenn schon, dann Meltdown, für Spectre gibt es, meine ich, noch nichts. Ist auch etwas schwieriger als bei Meltdown.
Mit der Performance wird es schon nicht so schlimm werden. 30% ist ein Grenzfall, passiert nur dann, wenn ein Prozess (fast) nichts anderes tut, als Systemaufrufe (wegen aktivierter PTI) . Bei Berechnungen dagegen wird es praktisch kein Unterschied geben.
Zitat von: hexenmeister am 07 Januar 2018, 10:14:44
Wenn schon, dann Meltdown, für Spectre gibt es, meine ich, noch nichts. Ist auch etwas schwieriger als bei Meltdown.
Mit der Performance wird es schon nicht so schlimm werden. 30% ist ein Grenzfall, passiert nur dann, wenn ein Prozess (fast) nichts anderes tut, als Systemaufrufe (wegen aktivierter PTI) . Bei Berechnungen dagegen wird es praktisch kein Unterschied geben.
Ich dachte Meltdown wäre eine reine Intel Geschichte (erst mal) deswegen hatte ich nur Spectre erwähnt.
Hab nachgeschaut, laut dem Netz ist Meltdown für A15 kein Thema. Zumindest wäre dann Docker oder KVM kein Thema.
Naja, der A15 core zieht ja seine Performance auch aus dem speculative und out of order gedöns.
Der A7 Teil ist ja nicht anfällig dafür da er das nich implementiert hat.
Grüße
Schnitzelbrain
Ja, soweit ich verstanden habe, ist Meltdown bis jetzt nur für Intel-Prozessoren nachgewiesen worden. Das klang für mich so, dass das für die anderen noch nicht generell ausgeschlossen wäre.
Zitat von: hexenmeister am 07 Januar 2018, 14:49:01
Ja, soweit ich verstanden habe, ist Meltdown bis jetzt nur für Intel-Prozessoren nachgewiesen worden. Das klang für mich so, dass das für die anderen noch nicht generell ausgeschlossen wäre.
https://github.com/lgeek/spec_poc_arm (https://github.com/lgeek/spec_poc_arm)
Wenn man vom Teufel spricht.
Schnitzelbrain
Zitat von: schnitzelbrain am 07 Januar 2018, 09:32:42
Schau mer mal was von der Performance übrigbleibt wenn die patches für spectre drin sind. :-(
Hab selbst den XU4Q Zuhause in Betrieb und den gerade wegen der Performance genommen.
Grüße
Schnitzelbrain
Unabhängig irgendwelcher Sicherheitslücken ... taugt der XU4Q was?
Was besseres für meine Anforderungen habe ich nicht gefunden.
Nachdem ich mir die Links zum Cubietruck durchgelesen habe, habe ich kein weiteres Interesse daran den noch zu "optimieren".
Das kostet mich zu viel Zeit und nerven, richtig verifizieren kann ich die Behebung dann ja auch nicht, oder erst in einem halben Jahr.
Mit einem Stresstest hat er sich bisher nicht in die Knie zwingen lassen. Weiß also nicht genau woran das liegt. Merkwürdig ist, dass das immer im Urlaub passiert...
Er ist ja auch schon ein paar Jährchen alt. Richte mir also eine Alternative ein.
Danke und Grüße
Dominik
Bei mir läuft er jetzt 3 Monate.
Bin noch am einrichten deswegen ist dauerbetrieb so ne Sache.
Bin noch zuviel am Basteln und rebooten.
Hab zwei CUL und USB3 HDD dran. ROOTFS ist auf der HDD und die SD ist nur für boot.
Schau mal auf unsere Wiki da sind die links zum Forum und so weiter für die XU4.
Bei mir war es die Leistung (zusammen mit dem Verbrauch) und die aktive Gemeinde.
Grüße
Schnitzelbrain
OK, Danke.
Hab den mal bestellt (auch wenn gerade nicht lieferbar ...)
Hab nen Homematic LAN Adapter und nen 433MHz CUL sowie eine USB 3 Festplatte im Betrieb.
Ne 2te USB 3 Festplatte hätte ich gerne noch, mangels Anschlüssen bisher aber nicht dran hängen.
Passt also mit dem XU4Q ganz gut denke ich.
Zitat von: elDudereeno am 07 Januar 2018, 17:43:03
OK, Danke.
Hab den mal bestellt (auch wenn gerade nicht lieferbar ...)
Hab nen Homematic LAN Adapter und nen 433MHz CUL sowie eine USB 3 Festplatte im Betrieb.
Ne 2te USB 3 Festplatte hätte ich gerne noch, mangels Anschlüssen bisher aber nicht dran hängen.
Passt also mit dem XU4Q ganz gut denke ich.
Ja, die haben vom C2 und dem XU4 im Dezember die komplette Produktion verkauft.
Bitcoin lässt grüßen.
Na dann drück ich dir die Daumen.
Schnitzelbrain
Ja ist Blöd wenn der FHEM-Server ausgeht.
Und wenn Du mal einen PI3 (oder ähnlich) mit FHEM als Reserve an der Fritzbox anschliesst.
WOL muss natürlich ein sein, das Pi3 dann mit Poweroff ausschaltest.
Wenn der Hauptserver aus geht kannst Du dann noch das Pi3 über die Fritzbox per WOL aufwecken.
Weiss aber wie das bei einem Stromausfall ist, ob dann das Pi3 auch startet.
Beim Nuc und bei der Zbox kann mann das einstellen, was nach Stromunterbruch zu machen ist.
Nach einer Stromunterbrechung kommt ein PI eigentlich wieder .. wenn das Dateisystem es überlebt hat.
ZitatNach einer Stromunterbrechung kommt ein PI eigentlich wieder .. wenn das Dateisystem es überlebt hat.
Gibt es irgend etwas das man bei der Installation machen kann, damit das Dateysistem es eher überlebt?
Zum Beispiel eine ip Kamera hat damit in der Regel keine Probleme.
Ich habe, trotz mehrfacher Stromausfälle durch "Problem-FI" bisher keine Probleme mit dem PI gehabt. Andere dagegen schon.
Du könntest probieren, möglichst wenig auf die SD-Karte zu schreiben ... bei mir ist der PI nur nackt als "Befehlsempfänger" und Cron-Daten-Sammler beschäftigt, also nicht FHEM, schreibt also relativ wenig.
Zitat von: elDudereeno am 06 Januar 2018, 13:06:23
Das ganze passiert immer im Winterurlaub, und manchmal auch unter-jährig. Insgesamt ca. 3 mal im Jahr.
Passiert denn im System was "besonderes" wenn das System in den Urlaubsmodus wechselt? Etwas was im "normalen" Betrieb nicht stattfindet?
Denke gerade an Heizung herunter fahren oder so. Wenn du diese Schritte manuell wiederholst, kann dann der Fehler reproduziert werden?
Wenn das System immer abstürzt wenn du im Urlaub bist, ist es ja mehr als ein Zufall.
Ich hab einen Pi3 mit HM_Uart und da maximal 20 Devices angemeldet.
Hatte noch keinen Ausfall, das möchte ich aber eben auch verhindern.
Wie gross muss die Speicherkarte für das PI3 sein wenn nur FHEM an Board ist?
Vielleicht lohnt sich da ein Speicher von Swissbit (SLC Speicher hat mir Mobotix empfolen für die T25 und C25, sollen extrem ausfallsicher sein).
Was ich speziel mache wenn SSD oder ähnlich eingebaut ist, ich lösche keine Daten, (log etc vom PI und Nuc).
Ob es hilft weiss ich natürlich nicht.
Warum soll das löschen von Daten bei einer SSD diese gefährden? Im Gegenteil: Seit es fstrim gibt, wird einer Verlangsamung verhindert.
Natürlich nur bei SSD (also nicht bei SD-Card)
Beim Nuc hab ich eine 120GB Festplatte.
Da ist nur Ubuntu und eben FHEM mit seinen Log Dateien drauf.
Ich will damit verhindern das immer auf die gleichen Bits geschrieben wird.
Die SSD sind da schon einige Jahre alt.
Habe gelesen das es neue SSD gibt, die einen SLC Modus haben.
Erst wenn dieser Speicher voll ist wird im normalen Modus weitergeschrieben
Wenn Du ein aktuelles Ubuntu hast (16.04), wird die Platte automatisch 1 mal die Woche "getrimmt", wenn es eine SDD ist.
Bein cubietruck hatte auch immer mal wieder unerklärliche abstürze.
Seitdem ich das im Igor Image standardmäßig aktivierte overclocking deaktiviert hatte, rennt er ohne Probleme durch. Ist heute seit 411 Tagen online :)
Gesendet von meinem Leap mit Tapatalk
Auch wenn das ganze hier schon älter ist:
Ich habe ebenfalls unerklärliche Abstürze von FHEM, wenn wir in den Urlaub fahren. Und wirklich nur dann! Ich sage mal wir sind gefühlt 10 km von zu Hause weg und FHEM stürzt ab. In den Logfiles finde ich nichts relevantes, da sind stellenweise die letzten Log-Einträge zwei Stunden vor dem Absturz und dann endet es einfach.
Meine Vermutung war schon, ob es damit zusammenhängen kann dass beide Handy (das meiner Frau und meines) gleichzeitig abwesend gehen die Ursache sind. Aber dann würde der Effekt auch mal auftreten, wenn wir abends einfach nur zusammen das Haus verlassen um was essen zu gehen. Da passiert es aber auch nicht. Und in Summe ist das super ärgerlich, da ich ja gerade wenn ich nicht zu Hause bin ich mich auf FHEM verlassen möchte, damit Rolladen wie gewünscht auf- und zu gehen, die Lichtsteuerung eine Anwesenheit simuliert und der Garten gegossen wird.
Ich nutze einen Raspberry Pi3 und hatte schon zweimal den Effekt, dass ein harter Reboot durch Stromweg die SD Karte gekillt hat. Somit ist für den Urlaubs-Crash leider keine zuverlässige Lösung, dass die nette Nachbarin mal rüber geht und den Pi vom Strom trennt.
Ich habe deshalb eine RAM Disk angelegt, in der FHEM seine verschiedenen Log-Files und save Dateien speichert, womit dann die Speicherbelastung der SD deutlich zurück geht. Die Logs werden per Cronjob in regelmässigen Abständen auf meinen Server kopiert und beim wieder hochbooten dann zurück in die RAM-Disk kopiert. Das läuft nun zwar seit 1,5 Jahren so, aber die Abstürze im Urlaub bleiben.
Vor einigen Jahren hatte ich auch einen Banana-Pi als FHEM Server im Einsatz. Der war eine Katastrophe, da er bei Rechenlast extrem heiß wurde und dann ausging. Süprich wenn FHEM mal was Rechenintensives gemacht hat, war er innert Sekunden glühend heiß und schaltete sich aus. Bin dann wieder auf den Pi zurück.
Für die Urlaubsabstürze habe ich jedenfalls keine Lösung gefunden und bin für Tips dankbar, wie man das einkreisen kann.
Steht was in den Linux-Logs? (kern.log syslog etc.)
Vielleicht will der Pi auch nur Urlaub machen, wenn "Herrchen" Urlaub macht ....
Der Nachteil von Logs im RAM: Bei einem Absturz sind die Weg und damit ALLE Debugmöchlichkeiten. Die Frage deshalb her: Was hast Du für einen Server, bzw. kann der als Log-Server herhalten?
Wenn Logs nichts hergeben, bleibt nur die Geräte nach und nach zu deaktivieren, bis man den Übeltäter gefunden hat. Anfangen würde ich natürlich mit der Abwesenheits-Logik.
Um Symptome abzumildern, würde zumindest ich sicherstellen, dass FHEM nach einem Absturz sofort wieder neustartet. Mit Systemd in den neueren Linux-Versionen ist das leicht zu erledigen.
bzw: Die Frage ist auch:
FHEM Absturz oder System-Absturz?
Gibt es eigene Regeln für den Urlaub? Eventuell dort suchen?