Abstürze seit letztem oder vorletztem Update?

[M_I_B]

... ist wie gesagt nur bei ein paar Logfiles auffällig ... Die Konfiguration ist von mir nicht verändert worden und okkinol RaspBian-like

Ich habe eben mal folgendes gemacht:
Das Verzeichnis /var/log komplett in ein 7z gesichert
Das Verzeichnis /var/log nebst aller Unterverzeichnisse geleert
Via SSH ein Reboot initiiert
Die dabei aufgelaufenen Logfiles in ein eigenes 7z gepackt (Anlage)

Wer mag kann sich ja mal die beim Booten generierten Logfiles ansehen; vielleicht fällt ja was auf, was mir mangels Wissen nichts sagt...

Jetzt ist das deutlich übersichtlicher und ich kann Änderungen besser erkennen... Dann warte ich mal auf den nächsten Absturz 

[rudolfkoenig]

Habe dmesg.txt un log.7z durchgeschaut: Samba ist (etwas?) kaputt, sonst sehe ich keine Probleme.

Das heisst, dass das Problem (FHEM-Exit/Absturz)  nur durchs sukkzessives deaktivieren einzelner Module oder durch strace zu identifizieren ist, wobei letzteres enorme Mengen an Daten produziert, und das System deutlich verlangsamt. Ich wuerde mit Deaktivieren versuchen, und dabei die "ungewoehnlichen" oder auf Netzwerk angewiesene Module als erstes probieren.

[M_I_B]

Habe dmesg.txt un log.7z durchgeschaut: Samba ist (etwas?) kaputt, sonst sehe ich keine Probleme.

... na Du kannst mir ja Mut machen Samba läuft eigentlich ohne Probleme, zumindest bemerke ich nichts von Problemen beim Zugriff ...
Ansonsten vielen Dank für's Durchschauen der Logs! Das schließt zumindest schon mal einiges an falscher Konfiguration aus...

Dann werde ich mal nach und nach die Module deaktivieren, nach jedem Abschmierer ein anderes Modul. Irgendwann hab ich den Burschen dann wohl mal am Schlawitchen

Ich habe mir den Thread in die Fav's gelegt und melde mich, sobald ich was neues zu berichten habe ...

[no_Legend]

Hast du noch mal ein Update heute gemacht?
Mein Cubie läuft seit diesem Update momentan noch.
Wie lange mal abwarten.

[M_I_B]

... meinst Du FHEM oder RaspBian? FHEM ist 4 Tage alt, RaspBian 2 ...

[no_Legend]

FHEM.
Heute kam ein update von FHEMWEB.

Wenn FHEM ein paar minuten durchält, probier mal ein Update zu machen.

[M_I_B]

... ik glob zwar net, dat es dran lüt ... aBär ik hav mol mocht 

RaspBian hatte auch einiges:

Code Auswählen Erweitern

Holen: 1 http://mirrordirector.raspbian.org jessie InRelease [14,9 kB]
Holen: 2 http://mirrordirector.raspbian.org jessie/main armhf Packages [8.980 kB]
Holen: 3 http://mirrordirector.raspbian.org jessie/contrib armhf Packages [37,5 kB]
Holen: 4 http://mirrordirector.raspbian.org jessie/non-free armhf Packages [70,3 kB]
Holen: 5 http://mirrordirector.raspbian.org jessie/rpi armhf Packages [1.356 B]


Also: Beides seit eben gerade auf dem neusten Stand ...

[M_I_B]

... da war er wieder, der Absturz-Troll 

Ich war heute Nachmittag unterwegs und als ich vorhin heim gekommen bin, stand die Kiste wieder. Ein "ps aux | grep [f]hem" brachte kein Ergebnis ...
Ich habe dann mal direkt die Logfiles gezogen. Auffallend ist, das FHEM wohl noch bis 15:16 gelaufen ist, die Masse der Logfiles aber identisch um 14:26 und 14:36 enden. Ist es nun Zufall, das am Ende immer eine "6" steht? Wenn ja, dann aber ein sehr merkwürdiger Zufall... Außerdem hätte ich erwartet, das FHEM sich in etwa zur gleichen Zeit verabschiedet; aber neeee, dat Dingen läuft exakt 30 resp. 40 Minuten weiter, bis es endgültig auf die Nase fällt...

Also wenn jemand der was davon versteht in den beigefügten Logs nichts auffälliges entdeckt, werde ich wohl RaspBian komplett neu aufsetzen und zeitgleich einen zweiten PI bestellen, der im Falle eines Versagens nach Umstecken direkt weiter das "Produktivsystem" in Betrieb hält

EDIT: Hochladen funktioniert nicht mehr (Fehler beim Speicher der Datei)?!? Hat doch heute Morgen noch geklappt... Sobald das wieder geht, reiche ich nach ...

EDIT2: >>> RPi_logs.7z <<< So geht's auch...

[rudolfkoenig]

Um 14:26:17 gab es einen "Server shutdown", ausgeloest vom PRESENCE_ProcessLocalScan (???). Merkwuerdig: Include-Pfade mit UTF-8 Zeichen wie  /opt/fhem/°INCLUDE°/... (*schauder*), scheint aber zu tun. 580 Definitionen: alle Achtung.

Um 15:16:52.651 war FHEM nch am Leben (FHEMWEB HTTP Aufruf mit /fhem/geo?...), danach meldet sich ueblicherweise der GEOFANCY Modul mit einer "GEOFANCY GeoFancy... " Meldung, aber nicht beim letzen Mal. Meine Vermutung: GEOFANCY ist die Ursache des FHEM-Todes.

[M_I_B]

Um 14:26:17 gab es einen "Server shutdown", ausgeloest vom PRESENCE_ProcessLocalScan ().

Ja, habe die Stelle jetzt auch gefunden; wie mag das zusammen hängen? Ich benutze PRESENCE zum Anpingen unserer drei Smartphones so wie dem TV. Zusätzlich frage ich über GeoFancy die Smartphones ab, um in Verbindung mit dem Ping eine gewisse Redundanz zu erreichen... Funktioniert eigentlich perfekt und mit (bis jetzt) 100% Trefferquote... Ist schon nett, wenn man in der Nacht heim kommt und das Außenlicht unabhängig von den (grottenschlechten) HM-Bewegungsmeldern schon bei Annährrung ans Grundstück an geht resp. nach Abschalten des TV nach und nach die Lichter aus gehen...

Merkwuerdig: Include-Pfade mit UTF-8 Zeichen wie  /opt/fhem/°INCLUDE°/... (*schauder*), scheint aber zu tun.

... jaja, ok... Windows- Jünger, geboren aus ZX80 und C64 Macht der Gewohnheit, um Sortierfolgen zu beeinflussen 

580 Definitionen: alle Achtung.

Danke für die Blumen! Wenn ich es als Lob verstehen darf, freut es mich um so mehr aus Deiner Hand...

Um 15:16:52.651 war FHEM nch am Leben (FHEMWEB HTTP Aufruf mit /fhem/geo?...), danach meldet sich ueblicherweise der GEOFANCY Modul mit einer "GEOFANCY GeoFancy... " Meldung, aber nicht beim letzen Mal. Meine Vermutung: GEOFANCY ist die Ursache des FHEM-Todes.

Das wäre jetzt aber echt doof. Ich bin ja froh, das Du den vermeintlichen Fehler gefunden hast, aber ausgerechnet das Modul gehört zu meinen Lieblingen Ohne das Modul funktioniert hier so einiges nicht mehr...
Was meinst Du? Ist das jetzt ein Problem des Moduls selber (KruschelCode), oder liegt das ggf. an irgend welchen Problemen bei den HTTP- Geschichten, die ja dann auch von OS-Seite Stress machen könnten? Ist der PI da evtl. kurzfristig so gestresst, das er Tasks/Daemonen einfach entsorgt?
Eigentlich könnte ich in dem Fall das Problem ja umgehen, wenn ich FHEM wie geplant auf den XEON packen könnte, aber dazu fehlt mir noch der auf LAN ungestrickte MiniCUL-(W)LAN, da ich ansonsten meinen ganzen IT-Kram, der auch teilweise zur Steuerung von HM eingesetzt wird, nicht nutzen kann... Notfalls würde ich auch als Zwischenlösung in einen PI3 investieren, der ja etwas fetter ausgestattet ist und sich später für andere Zwecke einsetzen lässt...
Kurz: Ist nun das PRESENCE resp. GeoFancy der Bösewicht, welcher RaspBian ans Bein pinkelt oder umgekehrt?

[pc1246]

Moin
Ich misch mich mal kurz ein. Nur ein kleiner Denkanstoss, da ich das mit den UTF-Geraffel jetzt schon oefter gelesen habe. Es gab da doch so eine kleine Aenderung von Rudolf vor kurzem, die auch was mit UTF zu tun hatte!? Betateilchen hatte da auch so seine Probleme, kann es eventuell in die richtung gehen?
Gruss Christoph

[M_I_B]

... ich weiß jetzt nicht, worauf Du dich beziehst; ist mal wieder an mir vorbei gegangen ... aBär: UTF-8 benutze ich seit Anbeginn bei FHEM (und allem anderen Zeugs hier). Das hat bisher auch nie Probleme bereitet, weder im Pfad, noch im Dateinamen, noch in den Dateien selber, so lange es keine Zeichen sind, die Windoof oder Linux für andere Zwecke nutzen (Punkt, Tilde u.ä.). Und da vorher alles damit funktioniert hat, tippe ich doch eher auf das PRESENCE oder GeoFancy - Modul. Das könnte auch eher zutreffen, weil ich vor nunmehr ca. 10 Tagen GeoFancy mit PRESENCE kombiniert habe. Also hat sich bei mir zum einen der aktuelle Softwarestand via Updates geändert, worauf sich meine in initiale Vermutung stützte, und PRESENCE / GeoFancy, worauf sich nun mein Augenmerk konzentriert.
Ich werde mal GeoFancy auskommentieren und mal nur mit PRESENCE via Ping arbeiten. Mal sehen, ob sich dann was ändert.

[ot] Ich würde es gut finden, wenn man via PRESENCE nicht jede einzelne IP einzeln, sondern als Block angeben könnte. Denn bei Einzelangabe laufen die PING's i.d.R. parallel und nicht sequenziell ab. gerade bei stark ausgelasteten Systemen wäre es m.E. besser, etwas in der u.s. Art definieren zu können, um eine parallele Abarbeitung auszuschließen:

Code Auswählen Erweitern

define IPcheck PRESENCE lan-ping 192.168.1.(130|131|132) {Abstand} {Intervall}
attr IPcheck IPalias 130 dieser, 131 jener, 132 welcher Selbiges könnte man ggf. auch für GeoFancy erreichen, um parallele Ereignisse nicht auch parallel abarbeiten zu müssen.
Ich habe zwar keine Ahnung, in wie weit die entsprechenden internen Abläufe den RPi belasten, aber irgendwie scheint ja das parallele Auflaufen verschiedener Ereignisse in dem Zusammenhang das System abzuschießen...[/ot]

[pc1246]

Moin
Sorry fuer die spaete Antwort. Gestern keine Zeit mehr gehabt! Ich hatte dies https://forum.fhem.de/index.php/topic,55421 gelesen. Und da kam mir der Verdacht, das es damit etwas zu tun haben koennte! Es taucht halt in letzter Zeit sehr viel bezueglich UTF8 auf! Und ja, es mag dann das entsprechende Modul betreffen!
Gruss Christoph

[M_I_B]

... so ... Kurzes Update:

@pc1246: Ja, möglich ist natürlich alles, auch die Sache UTF. Ich denke allerdings, das bei UTF- Problemen die Abschmierer häufiger/ständig und regelmäßiger kommen sollten, sobald irgendwo ein Zeichen aus dem UTF-Satz auftaucht. Da das aber nicht passiert, konzentriere ich mich erst einmal auf die letztlich hinzugekommenen Teile...

Da der Verdacht auf GeoFancy lag, habe ich erst mal alles was damit zu tun hatte auskommentiert und darauf basierende Abläufe deaktiviert oder umgebogen.

Das war nix... GeoFancy scheint unschuldig zu sein...

Nächster Verdacht resp. Test: PRESENZ
Ich habe das Gefühl, das hier das kontinuierliche Anpingen von 4 IP- Adressen in (derzeitigen) Intervallen von 20 Sekunden Probleme bereitet. Ich kann ja leider (wie ein paar Beiträge vorher angesprochen) nicht dafür sorgen, das die Pings sequentiell erfolgen. Auch wenn die Intervalle unterschiedlich eingestellt sind, so ergeben sich logischer Weise immer Zeitpunkte, an denen alle 4 Pings parallel erfolgen.

Idee: Ich bin leider ein Linux-DAU und kann das nicht selber, aber Folgendes ist mir gerade in den Sinn gekommen...
Könnte man nicht ein (Bash-)Script und/oder Cron schreiben, welches die gewünschten IP's sequentiell in Intervallen mit gewissem Abstand abfragt und damit ein Logfile oder etwas anderes generieren, was von FHEM lediglich abgefragt wird? Dann würde zumindest das Pingen nativ laufen und FHEM hätte damit zumindest nichts mehr zu tun, sondern erfragt nur das Ergebnis ...

[dev0]

Nächster Verdacht resp. Test: PRESENZ
...
Könnte man nicht ein (Bash-)Script und/oder Cron schreiben, welches die gewünschten IP's sequentiell in Intervallen

Teste erst einmal ob es bei Dir wirklich am presence Modul liegt. Wenn ja, dann würde ich auch zuerst versuchen die Probleme zu lösen.
Ein bash script sähe wie folgt uas:

Code Auswählen Erweitern


#!/bin/bash

/bin/ping 10.1.1.1 -c 1
if [ $? -eq 0 ]
then
   # Anwesend = 1
   /opt/fhem/fhem.pl <fhemhost>:7072 "<fhem-command>" "..."
else
   # Abwesend = 0
   /opt/fhem/fhem.pl <fhemhost>:7072 "<fhem-command>" "..."
fi                                     

/bin/ping 10.1.1.2 -c 1
if [ $? -eq 0 ]                         
then                                   
   /opt/fhem/fhem.pl <fhemhost>:7072 "<fhem-command>" "..."
else
   /opt/fhem/fhem.pl <fhemhost>:7072 "<fhem-command>" "..."
fi

...