FHEM Forum

Hallo liebe Leute,

seit einigen Tagen, nach dem letzten oder vorletztem Update vor ca. 1 Woche, habe ich mindestens einmal am Tag das Problem, das sich der FHEM-eigene HTTPd verabschiedet. RaspBian selbst läuft weiter und FHEM kann per SSH wieder mit einem Restart zum Leben erweckt werden.
Was ich noch nicht habe feststellen können ist, ob FHEM an sich weiterhin läuft und seine Befehle abarbeitet oder nicht... Im fhem.log zumindest ist nicht die mindeste Auffälligkeit zu erkennen ...

Habe ich nur das Problem? Und wo könnte ich noch nach den Ursachen forschen?

ZitatFHEM-eigene HTTPd verabschiedet

Ist damit FHEMWEB gemeint? Was heisst "verabschiedet"? Was heisst "FHEM kann per SSH wieder mit einem Restart zum Leben erweckt werden" genau? Falls FHEM komplett weg ist, und man keine Ahnug hat, in welchem Modul, dann hilft nur "attr global verbose 5".

Zitat von: M_I_B am 05 Juli 2016, 13:50:19
habe ich mindestens einmal am Tag das Problem,

wieso "das" Problem? Du hast doch in den letzten Tagen nur solche komischen Sachen...

Zitat von: betateilchen am 05 Juli 2016, 19:19:56... Du hast doch in den letzten Tagen nur solche komischen Sachen...

WOW! Echt hilfreich! Das die Leutz immer was zu sagen haben, wenn sie nix zu sagen haben ... ::)

Zitat von: rudolfkoenig am 05 Juli 2016, 18:58:36... FHEMWEB gemeint? Was heisst "verabschiedet"? Was heisst "FHEM kann per SSH wieder mit einem Restart zum Leben erweckt werden" genau? Falls FHEM komplett weg ist, und man keine Ahnug hat, in welchem Modul, dann hilft nur "attr global verbose 5".

verbose 5 ist seit heute natürlich aktiv; warte jetzt nur auf Wiederholung ...
FHEMWEB ist weg, zumindest hat es den Anschein. Jedweder Aufruf endet in einem "Keine Verbindung zum Server". Ob FHEM dabei komplett den Schläfer macht, kann ich (noch) nicht sagen. Ein " /etc/init.d/fhem status" meldet zumindest "running". Sobald das Problem wieder auftaucht, kann ich hoffentlich mehr berichten.
Per SSH zum Leben erwecken meint, das ich dumpf FHEM neu starte via "/etc/init.d/fhem stop|start"

"weg" ist aber auch eine Sehr ausführliche Fehlermeldung.

Gehe mal vor nach folgender "Anleitung":
https://forum.fhem.de/index.php/topic,54271.msg467373.html#msg467373 (https://forum.fhem.de/index.php/topic,54271.msg467373.html#msg467373)

Ich glaube, ich sollte es mal ins WIKI "prügeln" .....

... gerade wieder passiert ...
Ich war im DashBoard auf einem TAB, welcher zwei Plots darstellt, welche ich mit F5 so alle paar Minuten aktualisiert habe. Von jetzt auf gleich war der FHEM-Server via HTTP nicht mehr erreichbar (Firefox kann keine Verbindung zu dem Server unter 192.168.1.199:8083 aufbauen.). Ein Zugriff per Telnet ist ebenfalls nicht mehr möglich (Verbindung abgewiesen). Ein "/etc/init.d/fhem status" via SSH sagt aus, das FHEM nicht läuft.
Per SSH und SMB- Freigabe kann ich weiterhin auf den Server zugreifen und konnte so das aktuelle Logfile (mit Verbose 5) herunterladen, was inzwischen 250mb groß ist.

Am Ende des Logfiles hätte ich nun irgend etwas erwartet, was auf den Fehler weist, aber leider ist dort noch nicht mal ansatzweise etwas in der Art zu erkennen.

Ich habe das Proto mal ab 09:50:02 beigefügt; der Ausstieg erfolgte im Zeitraum bis 09:53:00 ... Also ich sehe da nix...

EDIT: Zu viel Log... Ich habe es als Datei beigefügt

EDIT2:
Ich hatte jetzt das FHEM-Log wegen der Größe gerade auf täglichen Wechsel umgeschrieben und wollte das alte LOG in ein 7z packen... Dabei ist dann der komplette RPi abgeschmiert. Also irgend etwas ist da glunzig... Ich habe schon die Befürchtung, das nicht FHEM hier die Abstürze generiert, sondern nur sekundär daran beteiligt ist und durch eine (kurzzeitige) hohe Last den RPi aus dem Tritt bringt, welcher dann wiederum bestimmte Dienste killt (welche die Last erzeugt haben) oder wie in dem Fall gerade sich vollständig verabschiedet...

Im FHEM-Log sehe ich auch nichts.
Kann man in "dmesg" was sehen? Laufen noch andere Dienste auf dem Rechner? Wieviel freien Speicher hat er?

... naja, ein paar andere Dienste laufen ja immer. Von mir wurde samba nachinstalliert und heute WiringPI, um damit dann einen Hardware-Watchdog ansteuern zu können...
Mit der Ausgabe von dmesg kann ich leider selbst nicht viel anfangen. Dazu fehlt mir Wissen, um daraus was ableiten zu können. Ich habe die Ausgabe mal in eine Datei umgeleitet und angehängt

mein cubie läuft auch nicht mehr stabil. Alle paar Stunden hängt dich fhem komplett auf.
In den Logs hab ich nichts gefunden.
Nur im kern.log hab ich was gefunden poste mal was da drin ist.

Zitat von: no_Legend am 10 Juli 2016, 21:57:45Nur im kern.log hab ich was gefunden poste mal was da drin ist.

... wenn Du mir verraten magst, wo genau ich das finde? Keinen Plan von Linux ...

Wenn du Linux hast
cat /var/log/kern.log

Schau mal ob du die gleiche Meldung bekommst wie ich:
https://forum.fhem.de/index.php/topic,55406.msg470660.html#msg470660

.... also wenn ich das richtig sehe, steht in "kern.log" genau das Selbe drin wie in der Ausgabe von "dmesg" ...
Solch eine Meldung wie die Deine habe ich nicht; da steht gar nichts mit Bezug zu FHEM drin...

Und ob ein Dienst läuft oder nicht, kannst Du 2gans schlecht" mit /etc/init.d/xxx sehen.

Besser ist da auf die Prozesse selber zusetzen, d.h.
ps aux | grep [f]hem
siehe auch mein Beitrag etwas weiter "oben" ...

Wenn Du eine genaue Zeit des Absturzes weist, kannst Du auch die "üblichen Verdächtigen" des Systemes durchsuchen, d.h. einfach mal unter "/var/log" gucken, ob sich eine der Dateien in der Zeit geändert haben und WAS dort reingeschrieben wurde!

ls -lha /var/log

... ok, da fehlen mir wie gesagt die Kenntnisse um zu wissen, das man via init.d nicht die selben Erkenntnisse erhält ...

Ich habe jetzt mal zum Spaß in diverse Logfiles reingesehen. Gehe ich recht in der Annahme, das [logfilename].1 der Vorgänger von [logfilename] ist und die eigentlich zeitlich fortgesetzt sein müssten? Denn auffällig ist bei einigen Logfiles zwischen dem File ohne "1" und mit "1" das Fehlen von 1-2 Tagen. Mag sein, das es normal ist, aber wie gesagt; nix Ahnung...

Ich werde die ganzen Logfiles mal wegsichern und aufräumen und dann mal auf den nächsten Abschmierer warten. Wenn das geschehen ist, werde ich die Logfiles erneut wegsichern, damit ich den Überblick behalte. Dann schaue ich mal, ob ich mit Eurer Hilfe da was finden kann...

Wenn Du (oder die Distri) das System so konfiguriert hast, da ja. Und wenn am Ende ein .gzu steht, wurden die alten Logfiles zusätzlich Komprimiert.

Da ich nicht weiß, wie Dein System (und Dein Logrotate) konfiguriert ist, bzw. in welchen Logfiles Du eine Lücke von "1-2 Tagen" hast, kann ich Deine Probleme nicht beurteilen.

... 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  ::)

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.

Zitat von: rudolfkoenig am 11 Juli 2016, 13:23:59Habe 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 ...

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

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

FHEM.
Heute kam ein update von FHEMWEB.

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

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

RaspBian hatte auch einiges:

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 ...

... 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 (http://cbxforum.de/files/RPi_logs.7z) <<< So geht's auch...

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.

Zitat von: rudolfkoenig am 11 Juli 2016, 23:06:55Um 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...

Zitat von: rudolfkoenig am 11 Juli 2016, 23:06:55Merkwuerdig: 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  ;D ;D ;D

Zitat von: rudolfkoenig am 11 Juli 2016, 23:06:55580 Definitionen: alle Achtung.

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

Zitat von: rudolfkoenig am 11 Juli 2016, 23:06:55Um 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 (https://forum.fhem.de/index.php?topic=42998.0), 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?

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

... 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: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]

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

... 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 ...

Zitat von: M_I_B am 14 Juli 2016, 09:54:39
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:

#!/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

...


Zitat von: dev0 am 14 Juli 2016, 10:14:30Teste 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.

Ja, schon dabei ... Bin gerade damit beschäftigt, die Smartphones komplett raus zu nehmen und dafür den TV massiv anzupingen... so im 1 sek Takt. Wenn PRESENZ der Böse ist, sollte FHEM resp. der PI recht zeitnah auf die Nase fallen... Wenn dem so ist, werde ich mal das Intervall variieren und schauen, wo die "Schmerzgrenze" liegt...

Zitat von: dev0 am 14 Juli 2016, 10:14:30Ein bash script sähe wie folgt uas: ...

Vielen Dank. Ist schon mal in den Snippet- Ordner gewandert, falls es demnächst benötigt wird

Zitat von: M_I_B am 14 Juli 2016, 10:28:24
so im 1 sek Takt.

WENN es vom presence Modul verursacht wird, dann eher durch gleichzeitige Abfragen, da diese geforkt werden (mehrere Instanzen) und entsprechende Resource benötigen. Dein 1 Sekunden-Test wird mWn sequentiell abgearbeitet.

... stimmt ... Ich dachte dabei in der Richtung, das ein Ping ja ggf. etwas länger als eine Sekunde benötigt, vor allem dann, wenn der TV offline ist. Wird in dem Fall nicht eine neue Instanz gestartet, wenn die vorhergehende noch nicht fertig ist?

Zitat von: M_I_B am 14 Juli 2016, 10:44:59
Wird in dem Fall nicht eine neue Instanz gestartet, wenn die vorhergehende noch nicht fertig ist?

Ich habe jetzt nicht ins Modul geschaut, aber ich denke nicht.

ZitatJa, schon dabei ... Bin gerade damit beschäftigt, die Smartphones komplett raus zu nehmen und dafür den TV massiv anzupingen... so im 1 sek Takt. Wenn PRESENZ der Böse ist, sollte FHEM resp. der PI recht zeitnah auf die Nase fallen... Wenn dem so ist, werde ich mal das Intervall variieren und schauen, wo die "Schmerzgrenze" liegt...

disable=1 sollte ja genügen zum deaktivierren.
wenn presence "schuldig" sein sollte, dann sicherlich eher, wenn mehrere presence zufällig gleichzeitig/parallel laufen. daher nehme ich an, dass der 1-sec test nicht viel zeigen wird. eventuell geofancy wieder aktivieren, da es auch die kombination deiner ganzen installation betrifft.

die sequenzierung der ping-checks müsste/sollte doch wohl auch über fhem/presence möglich sein.
zumindestens macht mir der befehl "set presence statusRequest" den eindruck.

ZitatSet
    statusRequest - Schedules an immediatly check.

zusammen mit at/sleep könnte das funktionieren.

... ok, ich mache mal folgendes:
Ich nehme alle SmartPhones wieder rein und setze incl. TV alles auf eine Sekunde. Dann passieren diverse Pings auf jeden Fall zeitgleich; macht auch mehr Sinn... war irgendwie auf dem Holzweg ;)

Zitat von: frank am 14 Juli 2016, 10:47:28disable=1 sollte ja genügen zum deaktivierren.

Für das Modul schon, aber da daran viele andere Teile hängen, laufen die auch nicht mehr. Die muss ich dann schon händisch auf einen anderen Trigger, und sei es nur ein Dummy, umbiegen ...

Zitat von: frank am 14 Juli 2016, 10:47:28die sequenzierung der ping-checks müsste/sollte doch wohl auch über fhem/presence möglich sein.
zumindestens macht mir der befehl "set presence statusRequest" den eindruck.
zusammen mit at/sleep könnte das funktionieren.

Ich tunmachen? Eher nicht ::) Ich werd's versuchen und versuchen, mich noch mal schlau zu lesen... Aber vielleicht ist es ja noch was ganz anderes... Mal sehen, was die Ping-Attacke bringt...

Nachtrag 1:
Eben gerade ist das Teil nach einem "shutdown restart" nicht mehr wieder gekommen. Verdacht Netzteil hat sich nicht bestätigt. Das liefert 5A bei sauberen 5,1V ... Das Setzen der Ping- Intervalle auf 1 Sekunde bei 4 teils nicht vorhandenen IP- Adressen scheint den aber nicht aus der Ruhe zu bringen ...

UPDATE:
Also PRESENCE resp. das Pingen ist es auch nicht... Jetzt wird es langsam schwierig...

Gerade beim erneuten Abschmieren ist mir rückblickend aufgefallen, das diese Abstürze offensichtlich bevorzugt am Morgen bei den ersten Zugriffen vom Client geschehen, also wenn ich mir einen Plot o.ä. anschaue. Da rufe ich 3-5 Seiten/Räume auf und dann kracht es.
Das irritiert mich etwas, da gerade in den Stunden des neuen Tages nicht all zu viel passiert. Um resp. nach Mitternacht werden die DayLight- und die Jahreszeit ermittelt, bei ausreichend Helligkeit am Morgen ein paar Aktoren abgeschaltet... bis auf die sowieso immer laufende Erfassung diverser Sensordaten passiert da nichts weiter. Und da diese Teile fast von Anfang an da waren, kann man die wohl als Verursacher ausschließen.

Im Moment bin ich erst mal vollkommen ratlos. Ich denke, ich werde mal auf Plan-B zurück greifen und RaspBian / FHEM komplett neu aufsetzen...

Gibt es einen möglichkeit zu schauen wieviele und welche module du benutzt?

Ich hab bei mir jetzt das mpd modul im verdacht.
Seit dem ich es auskommentiert habe läuft FHEM nun wieder stabil.
Woll im We noch mal testen ob es wirklich an diesem Modul liegt.

Zitat von: no_Legend am 15 Juli 2016, 09:28:50Gibt es einen möglichkeit zu schauen wieviele und welche module du benutzt?

Na Du kannst ja Fragen fragen ;) Keine Ahnung... Ich dachte, das benötigte Module während der Laufzeit geladen werden, wenn benötigt. Es gibt sicher ein Kommendo, um sich die benötigten Module anschauen zu können, aber ich habe keinen Plan, was ich da wo machen muss ...

Vll geht das mit Apptime?
Hast das schon probiert?

ZitatEs gibt sicher ein Kommendo, um sich die benötigten Module anschauen zu können

version

... danke Rudolf; auf "version" wäre ich jetzt im leben nicht gekommen ...

Was meint "No Id found for BlaBlub"?

Latest Revision: 11780

File                Rev   Last Change

fhem.pl             11756 2016-07-07 12:43:00Z rudolfkoenig
90_at.pm            11342 2016-04-29 11:25:51Z rudolfkoenig
98_autocreate.pm    11094 2016-03-20 09:41:03Z rudolfkoenig
00_CUL.pm           11637 2016-06-09 18:01:20Z rudolfkoenig
10_CUL_HM.pm        11685 2016-06-18 08:02:09Z martinp876
No Id found for 14_CUL_REDIRECT.pm
14_CUL_TCM97001.pm  11294 2016-04-21 20:32:28Z dancer0705
14_CUL_TX.pm        10140 2015-12-09 15:58:41Z rudolfkoenig
95_Dashboard.pm     10344 2016-01-03 11:29:48Z talkabout
98_DOIF.pm          11314 2016-04-26 18:29:24Z damian-s
98_dummy.pm         11442 2016-05-15 12:43:12Z rudolfkoenig
91_eventTypes.pm    10530 2016-01-16 19:27:21Z rudolfkoenig
01_FHEMWEB.pm       11772 2016-07-09 11:36:03Z rudolfkoenig
92_FileLog.pm       11336 2016-04-28 19:28:05Z rudolfkoenig
98_HMinfo.pm        11685 2016-06-18 08:02:09Z martinp876
00_HMLAN.pm         11645 2016-06-11 09:54:00Z martinp876
95_holiday.pm       10530 2016-01-16 19:27:21Z rudolfkoenig
02_HTTPSRV.pm       10733 2016-02-06 09:02:02Z borisneubert
No Id found for 10_IT.pm
91_notify.pm        11178 2016-04-03 14:20:32Z rudolfkoenig
73_PRESENCE.pm      11777 2016-07-10 14:03:35Z markusbloch
70_Pushover.pm      11616 2016-06-05 12:30:42Z loredo
33_readingsGroup.pm 11573 2016-05-31 06:54:52Z justme1968
16_STACKABLE_CC.pm   8666 2015-05-30 18:05:25Z rudolfkoenig
99_SUNRISE_EL.pm    10569 2016-01-19 06:30:28Z rudolfkoenig
98_SVG.pm           11771 2016-07-09 11:11:48Z rudolfkoenig
98_telnet.pm        11772 2016-07-09 11:36:03Z rudolfkoenig
99_Utils.pm         10570 2016-01-19 06:39:23Z rudolfkoenig
98_version.pm       11026 2016-03-08 07:25:45Z markusbloch
59_Weather.pm       11249 2016-04-16 17:03:47Z borisneubert
98_weblink.pm       10530 2016-01-16 19:27:21Z rudolfkoenig

Blocking.pm         11465 2016-05-16 11:56:10Z rudolfkoenig
DevIo.pm            11748 2016-07-06 11:35:04Z rudolfkoenig
HMConfig.pm         11645 2016-06-11 09:54:00Z martinp876
HttpUtils.pm        11758 2016-07-07 14:09:30Z rudolfkoenig
myUtilsTemplate.pm   7570 2015-01-14 18:31:44Z rudolfkoenig
RTypes.pm           10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm    11513 2016-05-24 17:56:05Z rudolfkoenig
TcpServerUtils.pm   11758 2016-07-07 14:09:30Z rudolfkoenig
YahooWeatherAPI.pm  11249 2016-04-16 17:03:47Z borisneubert

Ich habe den Eindruck, hier wird ein Grundkurs FHEM gemacht ;)

No Id heißt, das im Modul keine ID vorhanden ist. Das sollte nicht sein, hat aber erstmal keinen Einfluss auf Funktionalität.

Zitat von: marvin78 am 15 Juli 2016, 09:52:48Ich habe den Eindruck, hier wird ein Grundkurs FHEM gemacht ;)

... warum auch nicht ;) Im Ernst: Wer noch nie in die Verlegenheit gekommen ist, solche Informationen aus dem System zu holen, weil eben bis dahin alles lief, der hat sich ja i.d.R. nie darum gekümmert. Wenn Du ein neues Auto kaufst, kümmerst Du Dich ja auch erst um die Frage, wo denn der Hersteller den Diagnosestecker versteckt haben mag, wenn was nicht so läuft wie erwartet, oder? ;)

Zitat von: marvin78 am 15 Juli 2016, 09:52:48No Id heißt, das im Modul keine ID vorhanden ist. Das sollte nicht sein, hat aber erstmal keinen Einfluss auf Funktionalität.

Ok, alles klar; fällt Dir sonst ein Modul auf, was ggf. diesen Stress verursachen könnte? Für mich ist da nichts besonderes zu sehen ...

EDIT 1: DOS Attacke auf den Forenserver? War gerade bestimmt 15 Minuten nicht erreichbar ...
[ot]
EDIT 2: Ich habe gerade herausgefunden, wie man FHEM mit einer Definition wegknippsen kann...
define IrgendEin dummy
attr IrgendEin devStateIcon bla:blub ???:radengel
Man beachte die "drei Fragezeichen" ;D ;D ;D Damit fällt FHEM direkt auf die Nase... habe ich gleich mehrfach probiert, um keinen Dummfug zu reden... War natürlich ein Copy&Past- Problem...
[/ot]

Zitat von: M_I_B am 15 Juli 2016, 10:00:24
... warum auch nicht ;) Im Ernst: Wer noch nie in die Verlegenheit gekommen ist, solche Informationen aus dem System zu holen, weil eben bis dahin alles lief, der hat sich ja i.d.R. nie darum gekümmert. Wenn Du ein neues Auto kaufst, kümmerst Du Dich ja auch erst um die Frage, wo denn der Hersteller den Diagnosestecker versteckt haben mag, wenn was nicht so läuft wie erwartet, oder? ;)
Ok, alles klar; fällt Dir sonst ein Modul auf, was ggf. diesen Stress verursachen könnte? Für mich ist da nichts besonderes zu sehen ...

Nein. Ich schaue dann tatsächlich ins Handbuch (^=Doku), recherchiere und/oder bezahle jemanden dafür, das Auto zu reparieren (direkt oder über Garantie). Grundsätzliche Dinge (also wo der Blinker ist), weiß ich aber so ;)

Mit fällt hier nichts auf, was einen Komplettabsturz verursachen könnte., weiß aber nicht, was 14_CUL_TCM97001.pm, 14_CUL_REDIRECT.pm machen.

Zitat von: marvin78 am 15 Juli 2016, 14:22:36Nein. Ich schaue dann tatsächlich ins Handbuch ...

... na, hab ich doch, nur es eben nicht gefunden, wie man's macht ... Aber egal ...  8)

Zitat von: marvin78 am 15 Juli 2016, 14:22:36... weiß aber nicht, was 14_CUL_TCM97001.pm, 14_CUL_REDIRECT.pm machen.

Also m.W. ist TCM97001 für IT- Wettersensoren zuständig. Die tauchen hier gelegentlich via AutoCreate auf (Nachbarschaft vermutlich). Aber REDIRECT? Keine Ahnung ...
Na, ich mache mal am WE eine neue SDHC fertig und alles neu, dann Config zurück spielen und schauen, was geht. Ist vielleicht erst mal der schnellere Weg. Wenn die Probleme dann immer noch da sind, bleibt ja nur der PI selbst oder eine Unverträglichkeit der neusten Updates FHEM mit den neusten Updates RaspBian (oder so oder ähnlich oder wie auch immer...)

ZitatGerade beim erneuten Abschmieren ist mir rückblickend aufgefallen, das diese Abstürze offensichtlich bevorzugt am Morgen bei den ersten Zugriffen vom Client geschehen, also wenn ich mir einen Plot o.ä. anschaue. Da rufe ich 3-5 Seiten/Räume auf und dann kracht es.

schalte mal plotfork aus.

attr <FHEMWEB_device> plotfork 0

... musste mich erst mal schlau machen, was plotfork überhaupt ist; nun weiß ich es ;)

Danke für den Hinweis. Werde ich machen nach dem nächsten Absturz. Im Moment ist "er" unerwartet friedlich. Hat vielleicht was damit zu tun, das ich gestern RaspBian um etliche, im reinen Headless- Betrieb unnütze Anwendungen erleichtert habe... Wir werden sehen...

Radikalkur ...
apt-get purge gpicview xarchiver xpdf galculator scratch dillo midori netsurf-gtk omxplayer alsa-base alsa-utils penguinspuzzle python-pygame lxde-core lxde-common lxde-icon-theme lxinput lxmenu-data lxpolkit lxrandr lxsession lxsession-edit lxshortcut lxtask lxterminal lxappearance lightdm lightdm-gtk-greeter openbox ttf-dejavu-core fontconfig fontconfig-config fonts-freefont-ttf wpagui x11-common dbus-x11 desktop-base desktop-file-utils hicolor-icon-theme leafpad xdg-utils xauth gnome-themes-standard gtk2-engines raspberrypi-artwork wolfram-engine

dpkg --configure -a

reboot

apt-get update -y && apt-get upgrade -y && apt-get dist-upgrade -y && apt-get autoremove -y && apt-get autoclean -y && reboot

EDIT: Nach meiner RaspBian- Säuberungsaktion war erstaunlicher Weise ein paar Tage Ruhe; ich dachte schon, das wär's gewesen :-[ Heute Nacht gegen 00:33 hat er sich aber wieder verabschiedet; da war ich schon im Bettchen.
Jetzt schalte ich mal den PlotFork ab und dann schauen wir mal ...

Kurzes Update:
Das "Aufräumen" hat etwas geholfen, aber Abstürze waren immer noch sporadisch alle 1-2 Tage zu verzeichnen, manchmal auch in kurzen Abständen hintereinander. Das Deaktivieren von PlotFork hat zusätzlich Stabilität gebracht, aber die Abstürze nicht gänzlich eliminiert.
Zwischenzeitlich habe ich einen PI3 da. Sobald ich etwas Zeit finde, werde ich das System mal dahin umziehen. Im ersten Schritt werde ich einfach stumpf die SD- Karte übernehmen, um zu sehen, ob die Abstürze am OS und/oder (zu schlapper) Hardware liegen. Im zweiten Schritt ziehe ich dann FHEM auf ein komplett neu auf dem PI3 installiertes OS um...